Add releaseTime to schema

Short answer: Yes.
Long answer: lbryschema and currently lbrynet.schema have copies of protobuf files embedded in the repo. It would be a separate task to move all of the protobufs out of lbrynet.schema into types repo and make sure that everything still works.
@nikooo777 has expressed some urgency in needing the claim signatures and thus the "publish date" metadata field added. I figure we can do that first, release it, then go back and refactor things so that we move all of the protobufs currently in lbrynet.schema into types, but i may overestimating amount of work required and this might be a simple transition to do...
@shyba since you're working on this I'll let you decide which order of things makes the most sense, you can 1) move protobuf definitions out of lbrynet.schema and merge them into types repo and then work on claim signatures or 2) do claim signatures first and then move the protobufs. let me know what you decide.

I would like to reach a point where changing metadata definitions is simple and can be done independently of the SDK.
I don't feel strongly that we be there before adding releaseTime, but I'd be fine with doing them at the same time if that made sense. @eukreign can you make sure the required changes are filed, at least?

As of https://github.com/lbryio/lbry/commit/588779e3a4c942627545972c25715caa2d708abf lbrynet.schema.proto can be generated from types repo.


Installation fails

I'm trying to install the octane-tfs-plugin, but the installation fails.  Here are the details:
OS: Windows 10 Enterprise
TFS:

Version: 2018
Installed in: C:\Program Files\Microsoft Team Foundation Server 15.0
It's a local, working installation of TFS.  I'm able to host a project on it, use it for versioning source code (using Git), and connect my Visual Studio to it.  From my Visual Studio, I'm able to make a source-code change, commit-push the change, and it triggers an automatic build in TFS.  So my TFS installation seems to be stable and working.

Here's the error I get, when I execute setup.exe to install the plugin.  See the attached dialog.

I've even tried running the setup as Administrator, but I get the same error.

Hello, just wondering how the support process works for this plugin.  Will anyone be assigned to review my issue?

@jdperaza
hi , TFS 2018 is currently unsupported by the plugin.


feat: Validium mode

NOTE: This PR is the Validium base working branch.

Changes
The commits are self-explanatory, so I'll list them and briefly describe what has been made on them.

Add Validium mode example. This is a binary that implements an example that will be used for testing things out in both modes.
Use Ethereum's L1 gas price. To have more precise results, we're altering the gas costs for mainnet ones, Ethereum's L1 gas cost is between ~35-47 Gwei, and in zkSync mainnet the L2 fair gas price si 0.1  Gwei (the latter is untouched as it is already set).
Add --validium-mode flag to zk init command. This changes allow the system to run in Validium mode, spreading out the flag thought the codebase where it is necessary, and also setting the environmental variable for later era-contracts and zksync_server use.
Do not construct the pubdata in Validium mode. In Validium mode we do not want to send the pubdata to L1, our workaround on this for the PoC is to not construct it. For that, we read the VALIDIUM_MODE env set by the init.ts step.
Do not charge for pubdata in Validium mode. In Validium mode we also do not want to charge the user for pubdata, for that, thanks to the new fee model (V2) most of the changes can be done in the chain.toml file but one, this is l1_pubdata_price, which when set to 0 gives a huge gas use improvement in addition to the said config (yes, said config impacts the gas used by its own, setting l1_pubdata_price to 0 lowers more the gas usage).

Testing scenario
For comparing results between Rollup and Validium mode we are running the validium_mode_example binary with the system initialized both with zk init and zk init --validium-mode and running the server with zk server.
The validium_mode_example binary deposits some ETH to an account which will be used to deploy an ERC20 contract that is going to be called twice, for minting and transferring. For every mentioned action, some useful data like the transaction hash gas used will be printed to the stdout for later analysis.
In parallel, we are also using a debugging tool developed by Marcin that displays batch info. It is very useful to see data like L2 -> L1 messages, Large L2 -> L1 messages, Published bytecodes, and writes to the storage. As a TLDR, it is a server from which you can query batches by number and analyze said data. It's easy to know in which batch a transaction has been added with the eth_getTransactionByHash method.
In the section below you'll find a step-by-step guide to run said test scenario and see the results by yourself
Step-by-step
For running the example in Rollup mode

Run zk && zk clean --all && zk init to initialize the system in Rollup mode in a clear environment.
Run zk server to run the server in one console.
Run cargo run --release --bin validium_mode_example to run the Validium mode example in another console.
To run the Batch Status app

Clone https://github.com/mm-zk/zksync_tools and cd into it.
Run python3 operator/app.py.
Go to http://<IP_ADDRESS>:5000 in your browser.
Query by /batch/<batch_number>

For running the example in Validium mode

Run zk && zk clean --all && zk init --validium-mode to initialize the system in Validium mode in a clear environment.
Run zk server to run the server in one console.
Run cargo run --release --bin validium_mode_example to run the Validium mode example in another console.
To run the Batch Status app

Clone https://github.com/mm-zk/zksync_tools and cd into it.
Run python3 operator/app.py.
Go to http://<IP_ADDRESS>:5000 in your browser.
Query by /batch/<batch_number>

Results
Config:

Rollup
Validium

max_pubdata_per_batch
120.000
<IP_ADDRESS>.000

pubdata_overhead_part
0.7
0

compute_overhead_part
0.5
1

batch_overhead_l1_gas
1.000.000
1.000.000

internal_enforced_l1_gas_price
<IP_ADDRESS>
<IP_ADDRESS>

Fee Model

Gas Used

Ratio
Gas used Improvement

V1
Transaction
Rollup Mode
Validium Mode
Validium gasUsed  / Rollup gasUsed
Gas Difference / Rollup gasUsed

ERC20 Transfer
581.716
130.366

ERC20 Mint
810.134
129.284

ERC20 Second Deploy
1.884.480
163.230

ERC20 First Deploy
71.551.780
490.930

V2

ERC20 Transfer
794.116
140.431

ERC20 Mint
1.130.534
139.349

ERC20 Second Deploy
2.705.730
173.295

ERC20 First Deploy
TODO
500.995

Closing this PR as it is outdated. The new base will be #1015.
@RomanBrodetski we can the discussion on the GasAdjuster trait in https://github.com/lambdaclass/zksync-era/pull/145
@popzxc your assessment is correct, validium_mode_example/ was only meant for development and it wasn't a plan to take it to main. We're removing it in https://github.com/lambdaclass/zksync-era/pull/161 and made a similar integration test in https://github.com/lambdaclass/zksync-era/pull/144.
And regarding the Cargo.lock, I think it is now fixed in lambdaclass:feat_validium_pubdata_abstraction, but if not we'll fix it.


Can you fix the URL for the correct page to download the CE image?

File: engine/installation/linux/docker-ce/ubuntu.md, CC @mstanleyjones
W: Failed to fetch https://download.docker.com/linux/ubuntu/dists/jessie/stable/binary-amd64/Packages  HttpError404

Sorry, jessie is a Debian version, not Ubuntu. Try downloading something from https://download.docker.com/linux/debian/dists/jessie/.


only fix a reporting_frequency_code when the column exists

PR Overview
fixing weird "n" reporting_frequency_code encoder error.
alternatively, this filling in or frequency could happen in transform. but it would need to be applied in many of the tables' transforms.
still need to run the validation tests!
these are the validation errors I found. some are related to the EIA923m update (#2936).  the 714 ones are related to (#2999).
Why why the FERC1 errors?!?!
#2936
FAILED test/validate/mcoe_test.py::test_minmax_rows_mcoe[eia_monthly-capacity_factor-5178892-433286] - ValueError: capacity_factor: found 5178828 rows, expected 5178892. Off by -0.001%, allowed margin of 0.000%
FAILED test/validate/mcoe_test.py::test_minmax_rows_mcoe[eia_monthly-mcoe-5179300-433320] - ValueError: mcoe: found 5179236 rows, expected 5179300. Off by -0.001%, allowed margin of 0.000%

WTFERC?
FAILED test/validate/fbp_ferc1_test.py::test_fbp_ferc1_mismatched_fuels[ferc1_annual] - AssertionError: Too many records (9.53%) have mismatched primary fuel types.
FAILED test/validate/ferc1_test.py::test_minmax_rows[ferc1_annual-fbp_ferc1-26188] - ValueError: fbp_ferc1: found 25437 rows, expected 26188. Off by -2.868%, allowed margin of 0.000%
FAILED test/validate/ferc1_test.py::test_minmax_rows[ferc1_annual-fuel_ferc1-50039] - ValueError: fuel_ferc1: found 48887 rows, expected 50039. Off by -2.302%, allowed margin of 0.000%
FAILED test/validate/ferc1_test.py::test_minmax_rows[ferc1_annual-plant_in_service_ferc1-335750] - ValueError: plant_in_service_ferc1: found 315301 rows, expected 335750. Off by -6.091%, allowed margin of 0.000%
FAILED test/validate/ferc1_test.py::test_minmax_rows[ferc1_annual-plants_all_ferc1-56409] - ValueError: plants_all_ferc1: found 54535 rows, expected 56409. Off by -3.322%, allowed margin of 0.000%
FAILED test/validate/ferc1_test.py::test_minmax_rows[ferc1_annual-plants_hydro_ferc1-6979] - ValueError: plants_hydro_ferc1: found 6792 rows, expected 6979. Off by -2.679%, allowed margin of 0.000%
FAILED test/validate/ferc1_test.py::test_minmax_rows[ferc1_annual-plants_pumped_storage_ferc1-562] - ValueError: plants_pumped_storage_ferc1: found 544 rows, expected 562. Off by -3.203%, allowed margin of 0.000%
FAILED test/validate/ferc1_test.py::test_minmax_rows[ferc1_annual-plants_small_ferc1-16989] - ValueError: plants_small_ferc1: found 16269 rows, expected 16989. Off by -4.238%, allowed margin of 0.000%
FAILED test/validate/ferc1_test.py::test_minmax_rows[ferc1_annual-plants_steam_ferc1-31879] - ValueError: plants_steam_ferc1: found 30930 rows, expected 31879. Off by -2.977%, allowed margin of 0.000%
FAILED test/validate/ferc1_test.py::test_minmax_rows[ferc1_annual-purchased_power_ferc1-204720] - ValueError: purchased_power_ferc1: found 197829 rows, expected 204720. Off by -3.366%, allowed margin of 0.000%

#2999
FAILED test/validate/service_territory_test.py::test_minmax_rows[summarized_demand_ferc714-3195] - ValueError:  summarized_demand_ferc714: found 3105 rows, expected 3195. Off by -2.817%, allowed margin of 0.000%
FAILED test/validate/service_territory_test.py::test_minmax_rows[fipsified_respondents_ferc714-135627] - ValueError: fipsified_respondents_ferc714: found 135537 rows, expected 135627. Off by -0.066%, allowed margin of 0.000%

PR Checklist

[x] Merge the most recent version of the branch you are merging into (probably dev).
[ ] All CI checks are passing. Run tests locally to debug failures
[ ] Make sure you've included good docstrings.
[ ] For major data coverage & analysis changes, run data validation tests
[ ] Include unit tests for new functions and classes.
[ ] Defensive data quality/sanity checks in analyses & data processing functions.
[ ] Update the release notes and reference reference the PR and related issues.
[ ] Do your own explanatory review of the PR to help the reviewer understand what's going on and identify issues preemptively.

okay so what i've learned is that across the board we're currently loosing almost all of the FERC1 2021 records.

okay @jdangerx  I think i need your eyeballs on this.

it seems like whatever has changed in the xbrl extractor land is causing basically all of the 2021 data to go bye bye sad times.

at this point i think we should bubble these FERC1 and FERC714 validation errors off into their own separate issues.

@jdangerx perhaps ignore my previous comments.. it seems the nightly builds last night did not include the missing 2021 FERC1 issue. So this is almost certainly a local to me problem. Which is great for us and only low-key concerning for me :-)


⚠ Bofrost.at has degraded performance

In 04fec22, Bofrost.at (https://www.bofrost.at) experienced degraded performance:

HTTP code: 200
Response time: 1478 ms

Resolved: Bofrost.at performance has improved in 6867a9e.


now devices death

nice tool nice description
thank you now devices short light blue when connect to electricity and than nowhing
flash works finde all looks good but than death.
Before opening a new issue, please read the following
Are you reporting a successful flash?
Please add it to the wiki instead!
Do you have a question about configuring your newly flashed device?
Please ask in your alternative firmware's support channel instead!
Did you have issues getting a device to flash?
Please be sure to include your device name, model, and firmware version as well as your logs!
Please remember to close your issue when the problem has been addressed!

Please follow the instructions laid out before you, you need to include your logs to help determine the issue.

With no other information it sounds like your device is running the intermediate firmware. You can recover from this by restarting the process, as written in the Troubleshooting wiki.

Closing as unclear, unresponsive, and not enough information to debug.


Add scripts for deployment from git

This needs more work on performance to be something we can recommend in general, but it should provide a much nicer experience for testing out a version of Zulip off of zulip.git master for folks who want to do that.

Automated message from Dropbox CLA bot
@timabbott, it looks like you've already signed the Dropbox CLA. Thanks!

@rwbarton would you be up for testing this out, since I get the sense you're running a version off of master these days?
You probably need to add your repo URL in /etc/zulip/zulip.conf to make this work, but once that setup is done, you should be able to do just scripts/deploy-zulip-from-git master to deploy a new version.

Currently the experience kinda sucks because update-prod-static is really slow; to resolve that we'll want to do the things in https://github.com/zulip/zulip/issues/1458 (and maybe a bit more).

I checked out your branch, but something went wrong when building the release tarball (the "first one", which I was going to install on my server so that I could then test deploy-zulip-from-git):
\033[33mRunning update-prod-static; check /tmp/tmp.eSvXZtND4J/zulip-server-1.3.13tabbott-update-deployment/update-prod-static.log if it fails\033[0m

+ ./tools/update-prod-static
Traceback (most recent call last):
  File "./tools/update-prod-static", line 52, in <module>
    stdout=fp, stderr=fp)
  File "/usr/lib/python2.7/subprocess.py", line 540, in check_call
    raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['python', './manage.py', 'compilemessages']' returned non-zero exit status 1
(zulip-venv)vagrant@vagrant-base-trusty-amd64:/srv/zulip$ less /tmp/tmp.eSvXZtND4J/zulip-server-1.3.13tabbott-update-deployment/update-prod-static.log
/tmp/tmp.eSvXZtND4J/zulip-server-1.3.13tabbott-update-deployment/update-prod-static.log: No such file or directory

I think the update-prod-static log file being missing is because of a bug in the var/log transition;

The error itself was because I needed to provision; retrying...

Cool.  Also I just pushed a new version that adds documentation on how to setup this up, since that was previously not at all obvious :)

Merged, after @rwbarton finished testing this (discussion was on Zulip).  Thanks!


Broken link to the API docs

The link on the front readme is broken.  Namely the one on the line:
 The API full reference is available here http://guardtime.github.io/libksi/.

Readme.md updated with 295d491d72e58caadf891e8b9a0b1b5778c0dccc.


I want to use F1 macro metric but can not set it.

I want to use F1 macro to evaluate the model.
But I can only pass a string to name the metric.
For F1 I would have to add average="macro" to the compute call here:
https://github.com/huggingface/setfit/blob/2bc12c6e41c3241aced7f210185e447384ca1652/src/setfit/trainer.py#L303
What do you think? Did I miss anything?
I can contribute a PR if wanted...

Hey @PhilipMay thanks for spotting this! There's a PR to fix this in #125

Hey @PhilipMay thanks for spotting this! There's a PR to fix this in #125

Ok cool. Thanks. Closing this now.


DEVEXP-403: Mount cluster trusted CA to image registry operator

Injects the cluster proxy CA into /etc/pki/ca-trust/source/ca-bundle.crt

the other bit of this should be some logic in the operator itself to watch the mounted file.
(The file on disk will change if the configmap content changes).

the other bit of this should be some logic in the operator itself to watch the mounted file. If it changes, the operator should die (so it gets restarted).

@ricardomaraschini you and I will work on a follow-up PR to do this.
@bparees this PR will also stage the proxy CA that will be mounted into the registry itself - I assume we can use the same ConfigMap for both as long as the volume mounts are read-only.

@bparees this PR will also stage the proxy CA that will be mounted into the registry itself - I assume we can use the same ConfigMap for both as long as the volume mounts are read-only.

i'm not entirely sure what you mean, but the CM that's being annotated for proxy-ca injection needs to be used only for the proxy-ca, in the same way that CM's annotated for service-ca injection are used only for that.  They can't have multiple writers.

i'm not entirely sure what you mean, but the CM that's being annotated for proxy-ca injection needs to be used only for the proxy-ca,

My intent is that we only have one CM for the proxy ca (rename this trusted-ca?). This ConfigMap will be mounted into the registry operator as well as the registry pod - hence read-only mounting.
I assume we don't need to mount this into the nodeca daemonset, and that another operator will be responsible for this.

My intent is that we only have one CM for the proxy ca (rename this trusted-ca?). This ConfigMap will be mounted into the registry operator as well as the registry pod - hence read-only mounting.

yes mounting it in two different pods should be fine.

I assume we don't need to mount this into the nodeca daemonset, and that another operator will be responsible for this.

would be good to confirm with @mrunalp how they are handling it(not on this thread please) but i believe the intent is for the MCO to get the trusted CAs onto the nodes and CRIO should just pick it up from there.

would be good to confirm with @mrunalp how they are handling it(not on this thread please) but i believe the intent is for the MCO to get the trusted CAs onto the nodes and CRIO should just pick it up from there.
Yes, that's how it will work for CRI-O :+1:

Huzzah! No trust = no AWS storage (though we separately trust the apiserver?):
 {
            "apiVersion": "config.openshift.io/v1",
            "kind": "ClusterOperator",
            "metadata": {
                "creationTimestamp": "2019-08-01T15:58:23Z",
                "generation": 1,
                "name": "image-registry",
                "resourceVersion": "12484",
                "selfLink": "/apis/config.openshift.io/v1/clusteroperators/image-registry",
                "uid": "30c468a5-b475-11e9-a066-0afad4972984"
            },
            "spec": {},
            "status": {
                "conditions": [
                    {
                        "lastTransitionTime": "2019-08-01T15:58:23Z",
                        "message": "The deployment does not exist",
                        "reason": "DeploymentNotFound",
                        "status": "False",
                        "type": "Available"
                    },
                    {
                        "lastTransitionTime": "2019-08-01T15:58:23Z",
                        "message": "Unable to apply resources: unable to sync storage configuration: RequestError: send request failed\ncaused by: Head https://image-registry-us-east-1-ciop5nrpdzv2f0b2b5wzf6-30d741eeb47511.s3.amazonaws.com/: x509: certificate signed by unknown authority",
                        "reason": "Error",
                        "status": "True",
                        "type": "Progressing"
                    },
                    {
                        "lastTransitionTime": "2019-08-01T15:58:23Z",
                        "status": "False",
                        "type": "Degraded"
                    }
                ],
                "extension": null
            }
        },

Should s3.amazonaws.com be added to noProxy for aws installs?

Should s3.amazonaws.com be added to noProxy for aws installs?

If we use VPC endpoints for s3, then yes. Otherwise no - iirc traffic to s3 by default routes over the public internet.
Is our proxy controller smart enough to detect this?
fyi @openshift/openshift-team-network-edge

/hold
Blocked by https://github.com/openshift/cluster-network-operator/pull/274

/hold cancel
Once https://github.com/openshift/cluster-network-operator/pull/274 this should work!

@adambkaplan https://github.com/openshift/cluster-network-operator/pull/271 is also needed, but should merge tomorrow.

/retest

@adambkaplan https://github.com/openshift/cluster-network-operator/pull/271 has merged.

fail [k8s.io/kubernetes/test/e2e/framework/framework.go:338]: Aug 16 19:37:17.100: Couldn't delete ns: "e2e-test-build-webhooks-9brtm": namespace e2e-test-build-webhooks-9brtm was not deleted with limit: timed out waiting for the condition, namespace is empty but is not yet removed (&errors.errorString{s:"namespace e2e-test-build-webhooks-9brtm was not deleted with limit: timed out waiting for the condition, namespace is empty but is not yet removed"})
/test e2e-aws

/test e2e-aws
/test e2e-aws-image-registry
/test e2e-aws-operator
/test e2e-aws-upgrade

level=error msg="Error: Error creating S3 bucket: TooManyBuckets: You have attempted to create more buckets than allowed"
/test e2e-aws
/test e2e-aws-image-registry
/test e2e-aws-upgrade

/retest

/lgtm

/lgtm


docs: rename device-usb-camera in comments

Signed-off-by: Anthony Casagrande<EMAIL_ADDRESS>

Codecov Report

Merging #84 (f98d7c4) into main (78b2001) will not change coverage.
The diff coverage is n/a.

@@          Coverage Diff          @@
##            main     #84   +/-   ##
=====================================
  Coverage   1.88%   1.88%
=====================================
  Files         14      14
  Lines       1431    1431
=====================================
  Hits          27      27
  Misses      1395    1395
  Partials       9       9

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 78b2001...f98d7c4. Read the comment docs.


calc_Eaf should probably be calculated based on Aef instead of Af

Currently, calc_Eaf (final electrical consumption due to appliances) uses the input variable Af (conditioned floor area (heated/cooled) in [m2]). I think we should use the input variable Aef (floor area with electricity in [m2]) instead.
@JIMENOFONSECA: Is this a bug? Do we need to change it?

The answer to this bug needs to be added to the documentation in the calc_Eaf function on the documentation-and-refactoring branch.

Also, this function could easily be inlined (it is just a multiplication: Eaf = schedule * Ea_Wm2 * Aef)

Yes, all should be changed to that.
Best, Jimeno
On 12 Oct 2016, at 17:01, Daren Thomas <notifications<EMAIL_ADDRESS>wrote:
Also, this function could easily be inlined (it is just a multiplication: Eaf = schedule * Ea_Wm2 * Aef)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/architecture-building-systems/CEAforArcGIS/issues/360#issuecomment-253158316, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AIjrgkffF9RDJoG7YkMk3ikHqIMmAkJpks5qzKIBgaJpZM4KUhOI.

@JIMENOFONSECA, I'm not quite sure what you mean. What exactly should be changed?

change to Aef instead of Af
inline (remove function invocation)
find other such functions with this problem (candidates: calc_Elf)

all :-)
On 13 Oct 2016, at 3:50 pm, Daren Thomas <notifications<EMAIL_ADDRESS>wrote:
@JIMENOFONSECAhttps://github.com/JIMENOFONSECA, I'm not quite sure what you mean. What exactly should be changed?

change to Aef instead of Af
inline (remove function invocation)
find other such functions with this problem (candidates: calc_Elf)

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/architecture-building-systems/CEAforArcGIS/issues/360#issuecomment-253440232, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AIjrgo9TSBtaH_I7XIBGGqGi_h1bdfPzks5qzeKwgaJpZM4KUhOI.

fixed with PR #367


V2 generations of 2D and 3D primitives

WORK IN PROGRESS DO NOT MERGE
As discussed, here are the generation functions for the 2D and 3D primitives as converted to V2 geometry and math. Basically, the functions were created from the logic as found in the API layer, api/primitive directory. All the functions work fine, as I have verified that the solids produced are correct.
However... This is just the start of the reorganization, so some additional changes are expected.

The use of shape3 is mandatory. Are we going to keep the shape / geom split or merge? NO
How's the split of functionality? Does 'primitives' make sense. As a first try, this seemed sensible.
There's a lot of tests that need to be completed. These are difficult to produce, so any suggestions would be appreciated.

Changes Required:

[ ] Add simple checks of parameters; completeness, toxic combinations, etc. (API does type checks and/or conversions)

Test Suites To Be Complete:

[ ] Add tests for all variations of options
[ ] Add tests for error conditions

The concern that I have here is that these are tightly coupled with shape2 and shape3.
Could we change the generators to produce either (a) arrays of points, or (b) arrays of polygons.
And then compose those with calls to shape2.fromPoints, etc, separately?
Then we could use the circle generator to build a path instead, or run it through a post-processing function to do a novel kind of extrusion, or whatever else we like.

The other thing that I observe is that most of these aren't primitive, and could be easily decomposed into simpler forms using extrude, hull, etc.
So it might be that these belong in the user api, rather than core.

The other thing that I observe is that most of these aren't primitive, and could be easily decomposed into simpler forms using extrude, hull, etc.
So it might be that these belong in the user api, rather than core.

All of those options would add performance degradation. Hopefully, the primitives are exactly that...

pure math
correct geometry

I have a different pull request staged and ready. So, this pull request is not required.


IOU history not displayed when tapping on LHN badge

If you haven’t already, check out our contributing guidelines for onboarding and email<EMAIL_ADDRESS>to request to join our Slack channel!

Action Performed:

If you don't have already, create an IOU Transaction with any user.
Now send some random messages to that user more than 30 or 35. You can quickly do it on the web, just type a few letters in compose box then hit enter.
Now Logout of the app, so local data will be cleared.
Now Login back again try to tap on the IOU balance, you see won't see IOU Details History

Expected Result:

Describe what you think should've happened

Expected Result:
History of the IOU should be displayed.
Actual Result:
History of the IOU is not displayed when tapping on the LHN badge.
Workaround:
Can the user still use Expensify without this being fixed? Have you informed them of the workaround?
Platform:

Where is this issue confirmed?

Android
Web (send 50+ messages)

Version Number: 1.0.99-0
Reproducible in staging?: yes
Reproducible in production?: yes
Logs: https://stackoverflow.com/c/expensify/questions/4856
Notes/Photos/Videos: Any additional supporting documentation
https://user-images.githubusercontent.com/44479856/133857847-e20cfd19-3f89-46b4-9f71-e591eece3d05.mp4
Expensify/Expensify Issue URL:
Issue reported by: @Santhosh-Sellavel
Slack conversation: https://expensify.slack.com/archives/C01GTK53T8Q/p1631728889356900
View all open jobs on GitHub

Triggered auto assignment to @MitchExpensify (AutoAssignerTriage), see https://stackoverflow.com/c/expensify/questions/4749 for more details.

Triggered auto assignment to @alex-mechler (Engineering), see https://stackoverflow.com/c/expensify/questions/4319 for more details.

This issue is an n6-hold, so I'm going to drop the priority to weekly for now. After its off hold, I'll check back and see if it can go external

Still n6 holding

Unassigning for now to give other people a chance to grab it, since I'm focusing on another couple of things. I'll grab it back if no one else does!

This issue has not been updated in over 15 days.  eroding to Monthly issue.
P.S. Is everyone reading this sure this is really a near-term priority? Be brave: if you disagree, go ahead and close it out. If someone disagrees, they'll reopen it, and if they don't: one less thing to do!

@Julesssss This issue got closed without handling

Should fix, it's an internal issue though.

Made some progress on this today. I'm very aware of the offline changes doc, so I'm aiming for a command which is already compatible with (or very close to) the new API structure.
For now, the command takes a user email (for simplicity) and returns the IOUReport data along with the IOU reportActions.

Needs some improvements, but getting the IOUActions in addition to the report was straightforward:

PR in progress

Submitted a PR to fix the API: https://github.com/Expensify/Web-Expensify/pull/33842

Above PR has been merged. Front-end PR is in progress.

Holding while discussion about this APi takes place in the Manual Requests API refactor DD

The DD is nearing completion. Will be implemented shortly

The first mergeCollection PRhas been merged. Still blocked

This is in review, 4 PRs have now been merged related to this API refactor and fix.

THe final PR is about to be tested by QA.

Passed QA, just awaiting deployment now 👍

Issue is resolved now 🎉

@Julesssss Reporting bonus is not issue here

Reporting bonus is not issue here

Hey @Santhosh-Sellavel. Do you mean that we need to pay this still? If so I think we missed this because I resolved the issue myself. Let me know if that's correct!

Yes refer here

If it's a valid job proposal that we choose to implement by deploying it to production — either internally or via an external contributor — then we will compensate you $250 for identifying and proposing the improvement.

@Julesssss bump!

Hey @mallenexpensify, coulld you please create an UpWork issue so we can pay the reporting bonus. Thanks!

On it...
https://www.upwork.com/jobs/~01f706a2537b4de02f
@Santhosh-Sellavel , hired you, let me know when you've accepted and I'll pay.

Done, thanks Matt!

Paid @Santhosh-Sellavel !  Thanks
fwiw... i was testing the milestone payment process cuz of the upcoming Upwork<>GH integration ... nothing should be different though


Correct issues with infra startup scripts running in bridged mode

Rebased, and merged.
Thanks for your contribution !


Do not show the image with tag none

What would you like to be added:

Do not show the image with tag none
Why is this needed:
Cannot be deleted and makes no sense

Hey @offSwitch the images with no tag could be directly removed by using their image ID.

Hey @offSwitch the images with no tag could be directly removed by using their image ID.

This way I will delete all the images, but I only want to delete the images with tag none


Mouse cursor position on startup is (0, 0) until moved

The mouse isn't moved on startup, the position remains 0, 0.
(Has consequences if you have an interactive object on that spot, before the mouse is moved)
Can be fixed by adding the following in imgui-SFML.cpp::Init()
s_touchPos = sf::Mouse::getPosition(window);

Hello
Please check out this branch and see if it fixes the problem:
https://github.com/eliasdaler/imgui-sfml/tree/fix-init-mouse-pos

Closing as outdated. Feel free to re-open if someone stumbles upon this one again.


[SPARK-46043][SQL] Support create table using DSv2 sources

What changes were proposed in this pull request?

This PR supports CREATE TABLE ... USING source for DSv2 sources.
Why are the changes needed?

To support creating DSv2 tables in SQL. Currently the table create can work but when you select a dsv2 table created in SQL, it fails with this error:
org.apache.spark.sql.AnalysisException: org.apache.spark.sql.connector.SimpleDataSourceV2 is not a valid Spark SQL Data Source.

Does this PR introduce any user-facing change?

No
How was this patch tested?

New unit tests
Was this patch authored or co-authored using generative AI tooling?

No

cc @cloud-fan

The test failure seems unrelated.

thanks, merging to master!


Triple colon markdown not rendered

Accessing the model binding docs, e.g. https://github.com/dotnet/AspNetCore.Docs/blob/main/aspnetcore/mvc/models/model-binding.md all triple colon markdowns are not rendered.
Result is e.g.
:::code language="csharp" source="model-binding/samples/6.x/ModelBindingSample/Snippets/Controllers/PetsController.cs" id="snippet_GetById":::
This is happening in all model binding docs and also some other mvc docs, e.g. https://github.com/dotnet/AspNetCore.Docs/blob/main/aspnetcore/mvc/compatibility-version.md

Hello @KillerBoogie ... That's by-design because we don't intend the markdown documents to be used as the documentation. You must use the rendered docs. For example, the one you listed for model binding is here ...
https://learn.microsoft.com/en-us/aspnet/core/mvc/models/model-binding?view=aspnetcore-7.0

That's by-design because we don't intend the markdown documents to be used as the documentation. You must use the rendered docs.

Thanks. Now I understand.
The content of the rendered document at learn.microsoft just is not accurate: https://github.com/dotnet/AspNetCore.Docs/issues/29295


Getting UserWarning Users not migrated to use_structure permission, please add the permission manually warning

I am getting the following warning while migrating.
Please help

venv\lib\site-packages\cms\migrations\0010_migrate_use_structure.py:40: UserWarning: Users not migrated to use_structure permission, please add the permission manually
  warnings.warn(u'Users not migrated to use_structure permission, please add the permission manually')

This is happening intermittently.  so closing this issue as not critical


bump okhttp3

okhttp 3.4.1 has a known issue where connections can get stuck in an infinite retry loop (https://github.com/square/okhttp/issues/2756)
We saw this issue in the field with atlasdb's timelock server, and it resulted in all three timelock nodes plus two client service nodes (internal auth service) getting into a terminally unhealthy state and requiring a restart (essentially, all available application threads got into this state, and the services became unresponsive).
We've disabled okhttp-level retries for the time being (https://github.com/palantir/atlasdb/issues/2194), and are instead relying on Feign's default retry logic. However, okhttp claims that this issue is fixed in 3.4.2.

This is failing on
 Could not find com.palantir:gradle-baseline-java-config:0.9.2.
     Searched in the following locations:
         https://jcenter.bintray.com/com/palantir/gradle-baseline-java-config/0.9.2/gradle-baseline-java-config-0.9.2.pom
         https://jcenter.bintray.com/com/palantir/gradle-baseline-java-config/0.9.2/gradle-baseline-java-config-0.9.2.zip

Not sure why.

Have to add the bintray bucket explicitly, see baseline readme.

(I think the circle cached got cleared, so all builds on develop are now failing)

we're going to okhttp 3.8.1 in remoting3, so I think we can close this?


Manifold volume

Currently the volume function only depends on the manifold, but I think it should also take measure into account since some manifolds don't have a single universally accepted volume (see for example http://arxiv.org/abs/math-ph/0210033 ).

I also think that either connection or metric should be given.

It's even more complex, as there are other ways to measure the volume than from the Riemannian metric (see the paper I've linked), and connection is not sufficient as far as I know. I didn't even find a reference for chart-independence of the volume defined through the Riemannian volume form (just a claim on mathoverflow that it's true).

Here we use "volume" specifically to refer to the total mass of the unnormalized Hausdorff measure, i.e., the quantity that the Hausdorff measure must be divided by to make it a probability measure. The Hausdorff measure assumes a specific metric. When we don't use a MetricManifold, the metric assumed is the default metric for the manifold. So I think the use of volume with a manifold argument here is valid.
It might be more appropriate though to replace volume with total_mass, which takes as an argument a measure on a manifold. This would allow us to have the generic normalize(μ::AbstractMeasure) = inv(total_mass(μ)) * μ, which maybe should be defined in MeasureTheory.jl to avoid type piracy.
Does this sound right?

Isn't the Hausdorff measure only defined for submanifolds of R^n? It would make sense to me to have an interface for getting the volume of the manifold with respect to some other measure.

Isn't the Hausdorff measure only defined for submanifolds of R^n?

I believe it's defined for manifolds with an embedding in a metric space. So e.g. if one embedded the Sphere in R^n with varying radii, this would yield different volumes (surface area).
I need to figure out what I want to do with Hausdorff. It's primary use is as a base measure with respect to which log densities are usually defined. But one might want to change to a Lebesgue measure or vice versa, which is where the log_det_local_metric term comes in. In practice one would do this when reparametrizing a density defined in coordinates of the embedding to some other coordinate system. My current thinking is to use the atlas machinery in Manifolds for this, but I haven't given it much thought.

It would make sense to me to have an interface for getting the volume of the manifold with respect to some other measure.

Do you think the proposed total_mass would be a good way to do that?

I believe it's defined for manifolds with an embedding in a metric space. So e.g. if one embedded the Sphere in R^n with varying radii, this would yield different volumes (surface area).
I need to figure out what I want to do with Hausdorff. It's primary use is as a base measure with respect to which log densities are usually defined. But one might want to change to a Lebesgue measure or vice versa, which is where the log_det_local_metric term comes in. In practice one would do this when reparametrizing a density defined in coordinates of the embedding to some other coordinate system. My current thinking is to use the atlas machinery in Manifolds for this, but I haven't given it much thought.

Right, but maybe we'd like to use a Haar measure as a base measure for some group manifolds? It may be different from the Hausdorff measure. total_mass nicely solves this issue. I think 'volume' could be total_mass with respect to some default_measure (like we have default_retraction, default_vector_transport etc), but not necessarily the Hausdorff measure.
I think atlases should work as a way to change the measure to or from the Lebesgue measure. Just keep in mind that I haven't solved yet the issue of defining things like log_det_local_metric, which can be written by hand for a particular atlas (easy when you have a formula), or computed from the metric tensor (not particularly well tested).

Right, but maybe we'd like to use a Haar measure as a base measure for some group manifolds? It may be different from the Hausdorff measure. total_mass nicely solves this issue. I think 'volume' could be total_mass with respect to some default_measure (like we have default_retraction, default_vector_transport etc), but not necessarily the Hausdorff measure.

Great, okay, we're on the same page. Right now there's no notion of a default measure, but that could be added later. I think what @kellertuer needs is something a little more specific, like default sampleable measure, which would work for non-compact manifolds as well. Right now implemented measures just have a base measure, which is useful for defining log densities (and consequently we automatically get rejection sampling). Certainly some measures on groups will have a Haar measure as their base measure.

I think atlases should work as a way to change the measure to or from the Lebesgue measure. Just keep in mind that I haven't solved yet the issue of defining things like log_det_local_metric, which can be written by hand for a particular atlas (easy when you have a formula), or computed from the metric tensor (not particularly well tested).

Thanks for the heads up! I'll hold off on adding that functionality yet and just leave the optional atlas field as a placeholder.


Add XML context, Since XML and JSON share the Response, new concept: ResponseStorage.

[x] Add tests

:+1:

:+1:


script for running the code

Nice work! and thanks for sharing the code.
Will you show any demo/ script to run the code for the scene shown in the paper later?
Thanks!

If not a script, even steps on how to run the code will suffice.

Agreed, the excitement is killing us.

Agreed, the excitement is killing us.

Thank you very much for all your interest! Sorry for procrastinating on finishing the code release. I am a bit overwhelmed by all this interest as this is my first research project.
We will most likely get this in before the end of the break (3 weeks). If you can't wait, please email me and I can provide some private code for now, by early next week, but likely not every experiment will be in.
I will keep this issue open until all that is done.

Thank you very much for all your interest! Sorry for procrastinating on finishing the code release. I am a bit overwhelmed by all this interest as this is my first research project.
We will most likely get this in before the end of the break (3 weeks). If you can't wait, please email me and I can provide some private code for now, by early next week, but likely not every experiment will be in.
I will keep this issue open until all that is done.

Dear Alex,
Thanks for your kind gesture to provide the private code. How would I contact you?
Thank you!
Anil

Dear Alex,
Thanks for your kind gesture to provide the private code. How would I contact you?
Thank you!
Anil

@sxyu can you please also provide a google colab for inference thanks

@sxyu can you please also provide a google colab for inference thanks

I apologize if I couldn't respond to all of your emails :(.  In the end, I decided to simply release updated code to this public repository.
@ak9250 I will look into that, at least for real object experiment that's a good idea

I apologize if I couldn't respond to all of your emails :(.  In the end, I decided to simply release updated code to this public repository.
@ak9250 I will look into that, at least for real object experiment that's a good idea

@sxyu any update on this?

@sxyu any update on this?


[Errno 32] Broken pipe on command output (reggression or PR #236)

Hey, I was almost close to necro-bump #236 , but it seems this patch is not available on cleo-1.0.0a5 anymore. I discovered that while using a recent version of poetry:
$ poetry version  --dry-run -s patch | head -n 1
0.1.1

[Errno 32] Broken pipe
Exception ignored in: <_io.TextIOWrapper name='<stdout>' mode='w' encoding='utf-8'>
BrokenPipeError: [Errno 32] Broken pipe

Current version of cleo and potry (which use cleo):
$ poetry --version
Poetry (version 1.2.2)

$ pip freeze | grep cleo
cleo @ file:///~/.cache/pypoetry/artifacts/1c/64/4e/3535588c61539bf8675d193a6dca8b9541451019ae21fb31af535f0643/cleo-1.0.0a5-py3-none-any.whl

The git history of cleo is not very clear to me, I didn't really understood what happened between this PR, the main branch and the 1.0.0a5 tag. I also opened a bug in the poetry project #7014.

Currently, we are working on releasing Cleo 1.0, which includes a lot of fixes. What you see on main, is unfinished 1.0. Tag 1.0.0a5 was a release that started our work on restoring Cleo to a proper shape.
TL;DR not a regression, #236 is not released yet.


CI: Add delay between joining masters

Why is this PR needed?
After joining a master, some time is required to allow etcd to become stable. Trying to join another node may fail with diverse errors depending on the status of etcd at the moment of the join. For example:
E1120 04:33:15.495795   21470 ssh.go:192] error execution phase control-plane-join/update-status: error uploading configuration: etcdserver: request timed out
I1120 04:33:15.500262   21470 ssh.go:167] running command: "sudo sh -c 'rm /tmp/kubeadm-init.conf'"
[join] failed to apply join to node failed to apply state kubeadm.join: Process exited with status 1
F1120 04:33:15.677530   21470 join.go:62] error joining node caasp-master-101-caasp-jobs-e2e-caasp-v4-openstack-test-ci-1: failed to apply state kubeadm.join: Process exited with status 1

This is a well-known issue upstream and the only reliable way to walk around it is to force a wait (checking node status or etcd status is not reliable as may give false positives)
Fixes https://github.com/SUSE/avant-garde/issues/1061
What does this PR do?
Forces a delay after joining master nodes and exposes this delay as a testrunner argument.
Merge restrictions
(Please do not edit this)
We are in v4-maintenance phase, so we will restrict what can be merged to prevent unexpected surprises:
What can be merged (merge criteria):
    2 approvals:
        1 developer: code is fine
        1 QA: QA is fine
    there is a PR for updating documentation (or a statement that this is not needed)

Ah, okay, looking at https://ci.suse.de/view/CaaSP/job/caasp-jobs/job/caasp-v4-vmware-nightly/183/execution/node/44/log/, I see what's going on. We are checking healthiness correctly with kubeadm, the problem comes with the etcd blackout when growing from 1 to 2. We have been also adapting these timeouts lately on kubeadm.
One question, on every CI run, are we checking the disk speed with dd or something similar? It would be great to have this as well just to check if we are in a slow disk node or something similar. I wouldn't expect this etcd blackout to take this long on nodes that have been as short-lived as the ones on CI (maybe even with fast disks the etcd blackout can still happen for some time, if there's a lot to sync -- if the cluster has been up for a long time, or had many events).

@innobead this is an upstream issue. I've invested some time researching it and as @ereslibre mentions, the main factor seems to be the speed of etcd to become ready and this, in turn, depends on the disk and maybe also network. I wanted to check the readiness of the etcd itself calling it from the testrunner but it is not easy as I would need a client certificate. So  as @Itxaka says, let's fix the CI and keep investigating the root cause.

@ereslibre @jordimassaguerpla  tried to adapt the terraform to use local storage but apparently it was not easy. Maybe we could give it a second try?

@innobead this is an upstream issue. I've invested some time researching it and as @ereslibre mentions, the main factor seems to be the speed of etcd to become ready and this, in turn, depends on the disk and maybe also network. I wanted to check the readiness of the etcd itself calling it from the testrunner but it is not easy as I would need a client certificate. So as @Itxaka says, let's fix the CI and keep investigating the root cause.

yep, got your point. Let's do this way. thanks.


adding more info to the readme file

Adding info about sarufi
Adding info about neurotech africa

@Kalebu can you check this


Adding travis.yml for rocketchat notifications

Re-adding travis.yml to configure build
notifications to RocketChat

If you enable all the hooks that can flood a lot. It more meaningful to enable only one hook (e.g: on_failure). Or even on_change or similar if travis supports it


Documentation or small startup for writing plugins

Heyho and nice work with fusebox. Is there some how-to for writing own plugins. Best practice guides or a short intro. I'm working on implementing assemble as a fusebox plugin but the biq question mark is how to get started. Should we write in typescript, es6 or what is preferred. Who are the helper libraries working, what's up with Workflow Context. Would be great to get some starting points right now.

Official documentation is here: http://fuse-box.org/#plugin-api

if the Docs. above are not enough please reopen with better suggestion :)

I came here from Google, so I'm correcting this for other travelers. The new page is:
http://fuse-box.org/page/plugin-api

@tarwich thanks :)


TowersLOS.py needs to be updated for arcpy.mapping

TowersLOS.py needs to be updated for arcpy.mapping for Pro.
Currently lines 286 to 290:
mxd = arcpy.mapping.MapDocument('CURRENT')
df = arcpy.mapping.ListDataFrames(mxd)[0]
layerToAdd = arcpy.mapping.Layer(thisOutputFeatureClass)
arcpy.ApplySymbologyFromLayer_management(layerToAdd, layerSymLocation + "\Radial Line Of Sight Output.lyr")
arcpy.mapping.AddLayer(df, layerToAdd, "AUTO_ARRANGE")

Fixed this one.


where and how publish the docs

Navigating the gh-pages: https://lightbend.github.io/cloudflow-contrib
the banner for cookies keeps popping up.
How does it work?
cc. @rasummer @rstento @thothmoses

we discussed and decided to leave those docs in the GH pages at least for now.
I close this Issue and we re-iterate when necessary.
Thanks to everyone!


Remove random characters

Remove random characters from FilterParser.
#46337

The random characters are by designed for easier identification of where the message is.


Ant environment variable "ant.java.version" returns 1.8 for Openj9 SDK

Overview
We have a dependency on Ant environment variable "ant.java.version" in our logic in openjdk.build/include/top.xml (target check-for-tools-jar), where we are trying to figure out the SDK we are testing. If it's Java 8, we copy tools.jar in prereqs folder, if Java 9 we do not.
This however doesn't work very well, since Ant is returning 1.8 as the value for "ant.java.version" even when we are running on Open9.
To reproduce

Log into a Linux machine
Set JAVA_HOME to OpenJ9 SDK (e,g, http://vmtank.ottawa.ibm.com/vm_archive/R29/xa6490/ibuild_good/xa6490_openj9.zip)
Run: ant -diagnostics | grep ant.java.version -- it will print 1.8.

Note
Interestingly, if you do "ant -diagnostics" to print the full diagnostics of Ant while you have OpenJ9 SDK on the path, you get, among others, these value:
ant.java.version : 1.8
java.vm.version : 2.9
java.vm.vendor : Eclipse OpenJ9
java.runtime.version : 9-internal+0-adhoc.openj9.openjdk
java.fullversion : 9-internal+0-adhoc.openj9.openjdk
JRE 9 IBM J9 2.9 Linux amd64-64 Compressed References 20171025_368423 (JIT enabled, AOT enabled)
OpenJ9   - b13c187
OMR      - 604be15
java.awt.graphicsenv : sun.awt.X11GraphicsEnvironment
os.arch : amd64
com.ibm.vm.bitmode : 64
java.vm.specification.version : 9
java.version : 9-internal
So, as a workaround, in our top.xml, we could depend on "java.version" instead of "ant.java.version"
@lumpfish - any suggestion?

This issue blocks the openjdk-systemtest OpenJ9 build to be runnable in Ottawa.

Using java.specification.version - as a temporary fix (in my branch) to unblock the OpenJ9 build.


WIP: Improve analytics

Improve region selection analytics:

Old implementation recorded set event many more times than it actually
occurred
New implementation records only when user selects region
If region changes automatically on startup that is recorded in a
separate already existing event

Move app settings analytics to appDidBecomeActive:

Improves accuracy of app settings analytics as before Google Analytics would store events to be sent during the next session but if the next session did not occur on the same day Google Analytics would throw out the events.

Update: Working on adding Google Analytics to the Android app and found some more changes to make here so marking this as WIP.

@bbodenmiller Still interested in this PR?

Yes but I'm without a development environment right now. Hope to get that addressed in the next week.

@bbodenmiller any updates?

@aaronbrethorst currently stuck on https://github.com/OneBusAway/onebusaway-iphone/pull/259#issuecomment-74400162. Would like to get that fixed but if no one has any ideas I'll try to get around it so I can work on this PR.

It looks like this PR would fix https://github.com/OneBusAway/onebusaway-iphone/issues/376 that we noticed on iOS when testing OBA Android analytics.

@aaronbrethorst ready for review. This improves iOS analytics but does not address the comments in https://github.com/OneBusAway/onebusaway/issues/5 which are still ongoing and I will address in a seperate PR.

Looks good!


chore(deps): update go to v1.21.3 (patch)

This PR contains the following updates:

Package
Type
Update
Change

docker.io/library/golang

patch
1.21.2-alpine -> 1.21.3-alpine

docker.io/library/golang
final
patch
1.21.2 -> 1.21.3

docker.io/library/golang
stage
patch
1.21.2 -> 1.21.3

go (source)

patch
1.21.1 -> 1.21.3

Configuration
📅 Schedule: Branch creation - "on monday" (UTC), Automerge - At any time (no schedule defined).
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about these updates again.

[ ] If you want to rebase/retry this PR, check this box

This PR has been generated by Renovate Bot.

⚠ Artifact update problem
Renovate failed to update an artifact related to this branch. You probably do not want to merge this PR as-is.
♻ Renovate will retry this branch, including artifacts, only when one of the following happens:

any of the package files in this branch needs updating, or
the branch becomes conflicted, or
you click the rebase/retry checkbox if found above, or
you rename this PR's title to start with "rebase!" to trigger it manually

The artifact failure details are included below:
File name: undefined
Post-upgrade command 'make vendor' has not been added to the allowed list in allowedPostUpgradeCommands


Avoid nested Futures by calling combiners in a blocking manner

Added whenAllSucceedBlocking(), which waits for combiner to complete.
This is mainly to avoid returning nested futures in PushImageStep (although we are sort of OK with the nested futures because the combiner is meant to be called after the depending futures have been completed.) This will give an added benefit of better readability, as it was a bit complex to reason about the number of consecutive .get() calls or digest the meaning of returning ListenableFuture<ListenableFuture<BuildResult>>.
That said, PushImageStep will see a subtle difference in semantics regarding future execution (for example, an outer future may be scheduled to wait until an inner future completes prior to this change, while now an "outer" task will run explicitly after the "inner" task completes), but in the end, I believe the change doesn't matter because PushImageStep.afterPushSteps() is a private method, all those consecutive .get() calls just wait for all the tasks to complete in the same sequence after this change, and thus PushImageStep.call() is a blocking call ultimately.  I think wrapping tasks in Future here is an unnecessary layering, when we know how we chain the calls until blocking.

I would wait for @coollog to comment, since most of this async stuff was written by him.  I can't remember the original intention of nesting the futures.


Bump quic-go to fix security scanner

E.g.: https://github.com/kairos-io/kairos/actions/runs/12252916516/job/34180533523?pr=3066

What this PR does / why we need it:
Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Fixes #

Turns out it's not that simple. edgevpn breaks with this bump and fixing that would require bumping go-libp2p in edgevpn which it not a trivial fix.
We could get rid of the edgvpn dependency in tests if we simply called edgevpn with docker to generate a token.
E.g.
// Generates a valid token for provider tests
func generateToken() string {
	cmd := exec.Command("docker", "run", "--rm", "quay.io/mudler/edgevpn:latest", "-g", "-b")
	out, err := cmd.CombinedOutput()
	Expect(err).ToNot(HaveOccurred())

	return string(out)
}

but we still get edgevpn pulled as a dependency by go-nodepair used here.
That one we could also get rid of by calling kairos-agent register in docker but I can't decide whether I like were this is going.
After all, these are all repositories that will need to be fixed at some point. Maybe we should focus on that fix instead.


Implement 'Show all reports' a warning message when there are a lot of features to render.

Describe requirements
User reports " it would be nice to have an option to show all reports, and perhaps have a button that says 'Show all reports", but also have a warning message to let users know that they are about to load all active reports, and it will slow down the map. "
Alternatives
No response
Other Relevant Info
No response
Impact
No response

We currently don't have plans to implement this. We can consider if we get user requests on this.


Adaptive Card Support Enhancement: Templating And i18n

Use this query to search for the most popular feature requests.
Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
C# and Nodejs SDK both have support from adaptive card templating, ie using variables in the adaptive card and "expanding" it with values. However, there's no such support in Java.
Another related feature is i18n, for enterprise grade app, i18n is a must. However, without native support and with Templating missing, it's hard to implement i18n.
Describe the solution you'd like
A clear and concise description of what you want to happen.
Port Adaptive Card Templating from C#/Node to Java SDK
Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
Considering to try Thymeleaf or other templating engine as an interim solution
Additional context
Add any other context or screenshots about the feature request here.

Java SDK entered sustained engineering and will be retired November 2023.  New features will not be added during this time.  We will continue to support existing bots via critical bug fixes and security updates.

@tracyboehrer Thanks for the update. Thought I'm sorry for the MS's decision to discontinue the SDK. Java Ecosystem is thriving. Do you happen to have the official roadmap? We need to reevaluate our investment in the SDK. Much appreciated!


readme: add instructions for tests

It took me some time to figure out which features must be used for tests. So this pull request removes some friction.

bors r+


[BUG] - Components/Input

Describe the bug
The input is uncontrolled input. When I defined value={'somethings'}  on input then I can change the value of input. That is not in normal input tag behaviour.
Your Example Website or App
No response
Steps to Reproduce the Bug or Issue
The input is uncontrolled input. When I defined value={'somethings'}  on input then I can change the value of input. That is not in normal input tag behaviour.
Expected behavior
The input is uncontrolled input. When I defined value={'somethings'}  on input then I can change the value of input. That is not in normal input tag behaviour.
Screenshots or Videos
No response
Operating System Version
Windows
Browser
Chrome

<Input                             type={'text'}                             value={'Something..'}                             onChange={(e) => {                                 console.log(e.target.value);                             }}                             bordered                         />


[Event Request] New event on codeunit 27 "Confirm Management"

Hello everyone,
we would like to include an OnBefore-/ and an OnAfter event for the functions GetResponse and GetResponseOrDefault from codeunit 27 "Confirm Management" so that we can check in which transactions confirms are displayed.

Thanks in advance.

Why would you need that? Adding events here doesn't make a whole lot of sense. Could you elaborate a bit more for us to understand the scenario you are trying to support?

Perhaps I can answer your questions.
We have a situation where, for example, a warehouse employee partially posts a warehouse document and leaves the terminal while the process is running to look elsewhere or take a lunch break.
Now we have a setting for whether the remaining document should be deleted after posting, which can be set to never, always or after confirmation. The posting process takes a few seconds and, depending on the setting, a confirm appears asking whether the document should be deleted.
However, the warehouse employee no longer sees this popup and since it was triggered within a transaction, the database is locked.
We would therefore need a way of interacting with commits to log whether the commit was triggered in a transaction and by which process it was called.
With these events, we could check whether a transaction is still active and, if so, log the current call stack to know which process it originated from, so that we are always aware of such situations and can prevent them in advance.
In addition, such an event could be used to adjust the question text and the default button if necessary.

We've been discussing this back and forth and have finally landed on the conclusion to reject this event request.
First and foremost, the Confirm Management module is only used in about 50% of the cases where a confirm dialog is invoked. These events would hence only fire half of the time. Subscribing to those events would give a wrong sense of security.
Also, it seems like an anti-pattern to introduce generic events for specific purposes. If we know of a specific problem scenario, such as users leaving the terminal, we should rather introduce a dialog timeout, than an event. Or the specific scenario should be dealt with, by telling the user not to leave quite yet or by raising events in the scenario where the problem is.
We'd much rather understand the problems and deal with them, than to introduce events left, right and center in the entire product. On that basis, we won't introduce the events requested.


Change stylized writing from "ZigBee" to "Zigbee"

Zigbee Alliance has changed their stylized writing (and logo) of the Zigbee name from “ZigBee” to “Zigbee”, as in they are no longer writing Zigbee with a capital “B” in the middle of the name.
Home Assistant code (and website) still use the old stylized writing for the zha component and its device types:
https://www.home-assistant.io/components/zha/

Fixed in #17751

https://github.com/home-assistant/home-assistant.io/pull/7055


CI: Use versioneer to auto update project version, release CI part 1

closes #10

flowlauncher/_version.py and versioneer.py are added via versioneer package.
setup.cfg sets the style of version

This PR should be put on the agenda.

This PR should be put on the agenda.

When it is ready to be merged, it should use 'squash and merge'.


Refactor and clean-up handlers.

Five down (#511, #517, #519, #521, #531), two more to go for #510 and it's accompanying (p)refactor. This PR also has a proposed one-line fix for #527 (see comment on the given line).
Disclaimer
This is the penultimate and probably largest, most complex PR of the bunch. The obvious goal is to preserve most, if not all, of the existing behaviour. Unfortunately I do not have the setup to do the necessary testing that would make me 100% sure that I am not breaking anything (note to myself: introducing more solid unit-testing for the Slack bridge is a good next project ™). Current confidence factor is 80-90% given how many times I've analysed the code-path changes that I made and only external third-party review will be able to spot other things from here.
Summary
The goal of this PR is to break up the massive handleEventMessage() and skipMessageEvent() method which currently have cyclomatic complexities of respectively 40+ and 20+ whereas best practices and linting (gocyclo) usually start to scream at anything above 10. This PR leaves only the skipMessageEvent() method with a complexity of 11 and all the rest of the methods <=10.
Methodology
To accomplish these goals I have sliced up the existing code in independent logical units that each accomplish a part of the handling and filtering process. I've analysed the existing flow and the interdependence (or lack there of) of the various lines in the current function. This has brought me to the following pipeline and the corresponding implementation changes: each step now has its own sub-method (and potentially even sub-sub-methods for lower-level logical partitioning).

Check if the message should be ignored (i.e. the skipMessageEvent() method.

The skipMessageEvent() sub-method has been simplified by finding shorter equivalents for each existing logical expression.
The move of the skipping of particular attached files to step 5 of the pipeline in the handleDownloadFile() sub-sub-method.

Populate the Matterbridge message that will be sent to the router based on the received event and logic that is common to all events that are not skipped.

The populateReceivedMessage() sub-method.
The populateMessageWithUserInfo() sub-sub-method.

Detect and handle any message that is "status" related (think join channel, etc.). This might result in an early exit from the pipeline and passing of the pre-populated message to the Matterbridge router.

The handleStatusEvent() sub-method which has its logic condensed into a single switch statement.

Handle the specific case of messages that edit existing messages depending on configuration.

Straightforward and contained in the top-level handleMessageEvent() method.

Handle any attachments of the received event.

Separate handleAttachements() sub-method which calls the existing handleDownloadFile() sub-sub-method.
Attachments are now ignored at the sub-sub-method level if they are in the cache and recent.

Check that the Matterbridge message that we end up with after at the end of the pipeline is valid.

Straightforward and contained in the top-level handleMessageEvent() method.

NB: A digest of the above has been added to the code in the form of a comment on the handleMessageEvent() function.

Nice work! 👍
Some small comments, and then we can test it.
Are you a willing victim @patcon to help test this, you're an avid user of the slack bridge ?

@42wim I have reworked the populateMessageWithUserInfo() based on your feedback. And it made me realise that there was some stuff wrong with user info management which I also fixed.

I just also tried editing a slack message and the username is getting replaced by the slackuser ID (on the receiving bridge)

(haven't got the time right now to debug this further)
@patcon can you also test this PR in your setup ? because you have probably a lot of edge cases :)

Haha tons. I really want to learn more about got testing so I'm not the only one hitting these :)

@42wim don't worry about debugging it further yourself. This is my mess (and fault for coding with my brain on automatic). Will address it and ping you when ready.

@42wim have had a bit of a further look and I think it works now as expected w.r.t the users, etc.
Here's some screenshots of my (little bit of) testing between Discord & Slack:

NB: This is for Slack while only using a bot token associated with an app. As you can see it can perfectly impersonate the user that is sending the message when posting to the target Slack channel.

Just tried to run with webhookURL in slack (without token) and it panics.
Did some tests and it seems to be broken since commit 498377a230b8712792a47a61ad63ab746f7379d1
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x8 pc=0x9d3a40]
goroutine 1 [running]:
github.com/nlopes/slack.(*Client).GetConversationsContext(0x0, 0x10999c0, 0xc00003a4f0, 0xc0000301c0, 0xe37940, 0xc0008e96b0, 0x40e1d8, 0x10, 0xcf6580, 0xe37901, ...)
/nasfs/users/u0022146/go/pkg/mod/github.com/nlopes/slack@v0.4.0/conversation.go:462 +0xb0
github.com/nlopes/slack.(*Client).GetConversations(0x0, 0xc0000301c0, 0x17d1820, 0xbef044aeda696381, 0x641b74, 0x17d1820, 0x0, 0x0, 0xc000776360)
/nasfs/users/u0022146/go/pkg/mod/github.com/nlopes/slack@v0.4.0/conversation.go:456 +0x51
github.com/42wim/matterbridge/bridge/slack.(*Bslack).populateChannels(0xc0002328f0)
/home/u0022146/git/go/src/github.com/42wim/matterbridge/bridge/slack/helpers.go:126 +0x352
github.com/42wim/matterbridge/bridge/slack.(*Bslack).JoinChannel(0xc0002328f0, 0xc0004624c6, 0x7, 0xc000462480, 0xa, 0xe8452d, 0x5, 0xc0005651a0, 0x11, 0xc0005744b0, ...)
/home/u0022146/git/go/src/github.com/42wim/matterbridge/bridge/slack/slack.go:155 +0x2f
github.com/42wim/matterbridge/bridge.(*Bridge).joinChannels(0xc0001733b0, 0xc000575380, 0xc0005753b0, 0xceb4e0, 0xc000764230)
/home/u0022146/git/go/src/github.com/42wim/matterbridge/bridge/bridge.go:61 +0x2f0
github.com/42wim/matterbridge/bridge.(*Bridge).JoinChannels(0xc0001733b0, 0x0, 0x0)
/home/u0022146/git/go/src/github.com/42wim/matterbridge/bridge/bridge.go:53 +0x3d
github.com/42wim/matterbridge/gateway.(*Router).Start(0xc00056b360, 0xc00056b360, 0x0)
/home/u0022146/git/go/src/github.com/42wim/matterbridge/gateway/router.go:53 +0x392
main.main()
/home/u0022146/git/go/src/github.com/42wim/matterbridge/matterbridge.go:52 +0x5b0

@42wim have indeed reproduced as well myself now (you need indeed to remove the token). Will make a separate fix PR to fast-track it.

I rebased way back and ran into some issues (from other PR, I recall), but I'll give this another shot with the translation branch.

Now rebased on top of the fixed master.

Hm looks like it still needs a rebase, not sure how this can be if you rebased 3 hours ago

Probably due to the merge you just did of #508. But I'll rebase it in a moment.

Well. It wasn't that merge... Don't really know what confused the merge but it's fixed now. 😆

Thanks! Did some small tests and looks good 🎉
@patcon could you try master for a while to see if there isn't something that got overlooked?

Hitting this on my crazy translation branch: https://gist.github.com/patcon/1cc9983db575b3c27de4d9f8cdd84948
 time="2018-11-08T01:13:04Z" level=error msg="&errors.errorString{s:"could not find information for user with id U4MCXJKNC"}" prefix=sla

Will investigating later. Was working with master merged in right up until the last few PRs were merged.


676 destruction of derived swri subscriberimpl invokes ub

@danthony06 This should be ready for review now. I tested that it fixed the issues I was seeing in my workspace today.


fix: Explicitly set CGO_ENABLED=0

Summary

Explicitly set CGO_ENABLED=0 to make sure that dedicated console cli builds do not enable it automatically.
Test Plan

Checklist

[ ] If required, I have updated the Plural documentation accordingly.
[ ] I have added tests to cover my changes.
[ ] I have added a meaningful title and summary to convey the impact of this PR to a user.
[ ] I have added relevant labels to this PR to help with categorization for release notes.

@floreks Can you also enabled linux/arm64 builds of the console CLI while you're at it here?


Firebase Storage: Support scheduling uploads while offline

[REQUIRED] Step 1: Describe your environment

Xcode version: 11.6
Firebase SDK version: 6.30.0
Firebase Component: Storage
Component version: 3.9.0
Installation method: CocoaPods

[REQUIRED] Step 2: Describe the problem
Full disclosure: I'm having a hard time reproducing this issue. Additionally, while I am fairly confident that the problem lies in a recent Firebase SDK update, I can't prove it. Therefore, I am raising this issue with the information I have in hopes of getting the opinion(s) of the Firebase iOS team.
Our app allows users to create posts with an image that we upload to Firebase Storage. Until recently we were using SDK Version 6.18.0 without issue. In July we updated our app to use SDK Version 6.28.0 and rolled it out to production after not finding any problems during testing. After doing this, we noticed that some images were unexpectedly not being uploaded. Of the posts being created, approximately 1 in 10 are missing their image.- which will become a big problem if we can't quickly resolve it. After some review, we determined that there were no code changes on our end that should have had any impact.
The only changes to our app at this time were dependency updates- where Firebase was one of three dependencies updates. The second SDK was for Branch and the third for KeychainAccess- both seemingly unrelated. We recently updated from 6.28.0 to 6.30.0 and noticed no effect on image uploading. While updating the SDK, we also threw in a Performance trace to profile the image upload task so that we could see how long the upload process was taking. See the Relevant Code section regarding implementation of this trace. As for the results, we now have a few hundred samples and the metrics are interesting.
The images being uploaded have a median size of 574 KB, with a median upload duration of 2.18 seconds as shown below.

The median on WiFi is good, but the 95th percentile is 27.62 seconds which seems unusually long. When looking at non-WiFi, the median is 19 seconds with a 75th percentile of 66 seconds and 95th percentile of 272 seconds. Of course we expect that users with poor service will experience longer uploads, but these numbers seem excessive.

Finally, we can also look at error rates. Occasionally we are seeing an error in the closure that we record with Crashlytics (50 occurrences in the last 90 days), where the localized description is always An unknown error occurred, please check the server response.. We're not really sure what this means- but this is not a new issue, and was occurring prior our upgrade from 6.18.0 and is still occurring at a similar frequency in 6.30.0.
Looking at the upload duration split up by success/error, it would appear at first glance that the upload duration where the response was Success is very low. However, it only appears that way because the time scale is skewed- as the 95th percentile for duration with Failure responses is 9,687 seconds (yes, that's close to 3 hours). The 75th percentile for Failure is 3,777 seconds, also unusually long.

The 95th percentile for Success responses is 66 seconds, which demonstrates that even successful uploads sometimes do take very long. Knowing this, and knowing that the occasional error response we are getting is much less frequent than the silent upload failure we're more recently experiencing, our current theory is that the image sometimes takes so long to upload that the user may be exiting the app before the operation completes, and the upload may cease when the app resigns its active state and/or terminates.
Unfortunately, we only implemented this trace after we started noticing the problem- so we don't have data from before to compare it to. We can only venture to guess that these numbers we are seeing now are unusual.
Now, I've already checked the Release Notes history to see if there were any interesting notes for the Storage module, but what I am going to do next is study every module to see if downgrading the SDK is an option for us to troubleshoot. If this were consistently reproducible then we could test this easily in a development environment. Instead, because of our difficulty to reproduce, we would need to deploy the downgraded SDK to production. Doing this may be totally fine, but I am weary of causing problems because we'd be reverting half a year of SDK updates with several feature-adds and bug-fixes that may be relevant to us.
I'm curious is anyone on the Firebase team has any ideas about this. In the mean time, we'll keep poking around and will report if we find anything further. As a workaround and safeguard, we're also going to try caching the image locally until we receive a successful response.
Steps to reproduce:
No reliable method of reproduction, see Relevant Code for... well... the relevant code.
Relevant Code:
guard let imageData = someUIImage.jpegData(compressionQuality: 0.9) else { return }

let storageRef = Storage.storage().reference().child("foobar.jpg")
let metadata = StorageMetadata()
metadata.contentType = "image/jpeg"

let uploadTrace = Performance.startTrace(name: "uploadImage")
uploadTrace?.setValue(Int64(imageData.count), forMetric: "Size")

storageRef.putData(imageData, metadata: metadata) { (metadata, error) in
    if let error = error {
        uploadTrace?.setValue("Failure", forAttribute: "Result")
        uploadTrace?.stop()
        Crashlytics.crashlytics().record(error: error)
    }
    else {
        uploadTrace?.setValue("Success", forAttribute: "Result")
        uploadTrace?.stop()
    }
}

Hi @willbattel thanks for the detailed report and sorry for the issue you're seeing.
There weren't too many changes between those two versions and nothing sticks out to me as a potential issue.. but it's worth a look double checking these to see if anything was changed that could affect this.
git diff 6.18.0...CocoaPods-6.28.0 -- FirebaseStorage/CHANGELOG.md
diff --git a/FirebaseStorage/CHANGELOG.md b/FirebaseStorage/CHANGELOG.md
index 4a8af8699..f3edd66e9 100644
--- a/FirebaseStorage/CHANGELOG.md
+++ b/FirebaseStorage/CHANGELOG.md
@@ -1,3 +1,18 @@
+# 3.8.0
+- [changed] Add error for attempt to upload directory (#5750)
+- [changed] Functionally neutral source reorganization. (#5851)
+
+# 3.7.0
+- [fixed] Fixed a crash when listAll() was called at the root location. (#5772)
+- [added] Added a check to FIRStorageUploadTask's `putFile:` to check if the passed in `fileURL` is a directory, and provides a clear error if it is. (#5750)
+
+# 3.6.1
+- [fixed] Fix a rare case where a StorageTask would call its completion callbacks more than
+  once. (#5245)
+
+# 3.6.0
+- [added] Added watchOS support for Firebase Storage. (#4955)

(leaving out the CHANGELOG.md in the above command will show the actual contents of the changes between the two versions).
Can you share what version of GTMSessionFetcher is being used? Ideally both before and after the upgrade. As far as I recall off the top of my head, Storage uses GTMSessionFetcher under the hood for almost all networking interactions.
One thing that just popped into my head as well: do you have iOS versioning stats for this? Considering iOS 14 beta is still out and growing, I'm wondering if this was introduced in iOS 14 and just happened to line up with your upgrade timing. (Side note: something very well could be wrong inside the Storage SDK and I'm not trying to pass the blame, just trying to see if there are patterns that we can use to help make whatever changes are needed in the SDK 😄 )
We had also seen an issue at one point where some networks were blocking access to Storage (#4913 where it happened on Comcast) and I'm wondering if something similar is going on as well. Either way, that extra info would help and we can try to see if there's anything that could be causing this.
As always, if you happen to find a repro it'll vastly accelerate us being able to track things down. Let's hope we can get your issue fixed soon, thanks!

Thanks for the comments, Ryan. I'll collect more info and report back later this week.

Hey @ryanwilson I've done a little more digging.

Can you share what version of GTMSessionFetcher is being used? Ideally both before and after the upgrade. As far as I recall off the top of my head, Storage uses GTMSessionFetcher under the hood for almost all networking interactions.

GTMSessionFetcher was upgraded from 1.3.0 to 1.4.0 during this time. Additionally, we discovered that the problem may have existed in some capacity when we were on SDK version 6.18.0 after upgrading from 6.13.0.
As a means of troubleshooting, to narrow down the possibilities, we are releasing a patch build to production where we have forced GTMSessionFetcher back to 1.3.0. We will monitor the Performance trace to see if there is any difference.

One thing that just popped into my head as well: do you have iOS versioning stats for this? Considering iOS 14 beta is still out and growing, I'm wondering if this was introduced in iOS 14 and just happened to line up with your upgrade timing.

It's a good thought for sure, but this problem has been reported on iOS 11, 12, and 13.

We had also seen an issue at one point where some networks were blocking access to Storage

I wondered about that too- I had read that issue prior to posting this one. The problem is so indiscriminate and inconsistent that I'd be surprised if it were related. That being said, the fact that reproduction is so difficult for our team makes it a possibility- however unlikely.

As always, if you happen to find a repro it'll vastly accelerate us being able to track things down.

This is what's really grinding my gears haha! There are so many occurrences but we can't find a pattern.

There is one more possibility that hadn't occurred to us until recently: the problem may have always existed but was unnoticed until recently when two things changed on our end. The first change was that our user base grew significantly during this time, so there were more opportunities for the problem to happen. The second, more direct reason, I describe below.
As mentioned in my original comment, we are uploading these images as components on user-generated posts. The post contents are kept in Firestore with a URI field to the image in GCS. Google does not support cross-product transactions, meaning we can't atomically write both the Firestore document and GCS image together- they have to be separate operations.
Prior to this problem being noticed, we had always uploaded the image to GCS and awaited a successful response before writing the metadata to Firestore. This ensured that the image was uploaded when we created the Firestore document. The problem with this flow was the possibility of orphaned images, where after uploading the image the Firestore operation doesn't complete.
As a measure of good data hygiene, we shifted to running the Firestore operations FILO relative to their GCS counterparts. This ensured that in the event of any orphanage, the orphaned data would be on Firestore and therefore much easier to detect and handle. As far as we know, there isn't a very efficient way to find orphaned objects in GCS. On paper, having Firestore run FILO seems like a good idea, because we can be confident that we aren't leaving any abandoned data behind.
Of course, this change surely could have brought this issue to light. This problem may have very well always existed, but it would not have been noticed because we were only creating the Firestore document upon successful GCS operations. The problem would have been masked because the Firestore document- which is what represents the post- would not be created if the upload doesn't succeed.
Assuming that this is indeed the defining difference that exposed the problem that had already existed quietly, the question changes to how we address it. If you look at the code snippet in my original comment, we aren't doing anything fancy. The fact that this upload operation averaging well under a megabyte is failing so frequently is strange to us. We're not really sure how to make it more resilient than it already is, other than maybe manually caching the images ourselves and retrying the upload operation periodically until it succeeds- but this would seem redundant to the mechanisms already present in the Firebase Storage SDK.
So the big question is, why are 1 in 10 upload operations failing on what should be a resilient platform? Our users aren't all farmers living in the middle of nowhere. Also, we can practically see the Storage SDK attempting to retry given the metrics we are seeing tagged as "Failure" showing 3 hours of upload time before finally giving up.
The only course of action that we would expect to reverse this would be to revert to GCS-first operations, knowing that we are only masking the problem and not truly solving it. We don't see any clear solution- other than Google supporting Firestore+GCS atomicity which we don't see happening any time soon (which is a shame because I think those products are very frequently paired together). We could send both the image and metadata to a Cloud Function to be handled there, but if the Storage SDK can't upload the image then odds are the Cloud Function request won't make it to the server, either.
These questions I've asked are all rhetorical- we don't expect anyone at Firebase to know why this is happening. But if you have any suggestions, we are all-ears.

Speaking further to this idea, there has been some further discussion on our end that I would like to share.
We believe that, while there may or may not be a problem with the Storage SDK, what is really exacerbating the situation we are seeing is the fundamental difference in how the Firestore and Cloud Storage clients work.
Firestore is quite intelligent; its offline persistence feature ensures that the local writes are available to the client for reading regardless of connectivity, and that the writes will eventually propagate to the server when the app is back online. When the client creates a new document in Firestore while internet connection is limited or unavailable, that document will be readable in much the same way as when using a high quality connection. This feature is fantastic...but can lead to friction when paired with other products such as Storage.
Firebase Storage is much simpler than Firestore when it comes to read/write operations. While the Storage SDK is designed to be robust, it does not share the offline persistence mechanism found in Firestore. This means that when an upload fails, that's it. There are no do-overs or eventual consistency/propagation like in Firestore. What's more is that there is no concept of "local storage" in the Storage SDK, so if we want to download an object that was very recently uploaded from the same client- even the same session- the Storage SDK will retrieve it from the server in the same manner as if the object had never at any point existed on the client.
In a perfect world, cross-product transactions would be supported and the Storage SDK would keep local copies of recently uploaded files to be used in download operations. Because our world is far from perfect, the best we can do is ask for these nicely and try to make it work as-is. Our current plan is to keep local copies of the images we upload until the operation completes successfully. On each session start we will retry the upload for any remaining images. Then, a new boolean field can be added to the Firestore documents to indicate if the image has been uploaded- so that we can more gracefully handle cases where the image upload is still pending.
Let me know what you think about all of this. Firestore and Storage are used together so commonly that we can't help but wonder what patterns other developers have adopted, or what is recommended by Firebasers.

I will take a look at this next week.

@willbattel Sorry for being a bit slow here.  If I summarize this in my own words, we have now come to the conclusion that while we now have more metrics, the problem likely exists in all versions of the SDK and all versions of iOS.
There seem to be a couple ways forward:

Implement property offline support in the Firebase Storage SDK. This is actually a long-standing feature request, but we haven't gotten around to it yet. We can look at this again in the future, but we haven't been able to prioritize this against other feature work.

Cap the total time that uploads are allowed to take. We already have maxUploadRetryTime, but I did just receive a report that this may not always work on iOS. Is this something that you have tried?

Figure out why the retries in GTMSessionFetcher do not work for 10% of your uploads. For this, we would likely need more information (e.g. the errors returned from the API). Do you have access to these error codes?

No worries about the delay, we've started developing a partial workaround in the mean time. We're going to cache a limited number of recent uploads and attempt to use the cache before downloading from Storage. We're also going to add a pending flag to associated Firestore documents with a garbage collector that periodically removes documents whose images never made it to the server.
I agree that offline support, at least to some degree, would be a great addition to the Storage SDK. I also suggest starting a discussion on improving the synergy between products, such as between Firestore and Storage. This is a much taller order but it seems that these products are used together so often that the added value would be worth the effort. This is outside the scope of this issue so I won't press it any further here, but if you're open to continuing the conversation I'd be more than happy to add further information.
Regarding the maxUploadRetryTime setting, we have not yet tried this but may do so just to see what happens. I'll let you know if there is anything to report from this.
Regarding the 10% failure rate, we're not seeing many errors. We record failures with Crashlytics but we only get the occasional An unknown error occurred, please check the server response which only happens maybe 1 in 500 uploads and doesn't really tell us anything. It seems like the app tends to be resigned, either to the background or terminated altogether, before the Storage SDK gives up on the upload attempt- as would explain the Performance metrics above. Maybe the maxUploadRetryTime can help force an error rather than allow Storage to run with it for hours and hours.

We also received an internal report: b/172486653

One follow up: Are you using https://developer.apple.com/documentation/foundation/nsurlsessiontaskdelegate/1643148-urlsession directly or pulling in dependencies that might be collecting metrics using the URLSession:task:didFinishCollectingMetrics API? GTMSessionFetcher just added support for this API endpoint (via https://github.com/google/gtm-session-fetcher/issues/187).

One follow up: Are you using https://developer.apple.com/documentation/foundation/nsurlsessiontaskdelegate/1643148-urlsession directly or pulling in dependencies that might be collecting metrics using the URLSession:task:didFinishCollectingMetrics API? GTMSessionFetcher just added support for this API endpoint (via google/gtm-session-fetcher#187).

No, we aren't using that API- though it might be a good idea for us to do so.
The good news is that, for reasons unbeknown to us, the upload failure rate seems to have reduced. Furthermore, we believe that many of our upload problems are actually caused by the app being resigned to the background or being terminated before the upload completes. The resolution of https://github.com/firebase/firebase-ios-sdk/issues/147 would then likely help alleviate some of this problem. Additionally, when the app is terminated, we would like for the Firebase Storage SDK to automatically resume/restart pending upload requests when the app is launched. The other side to this problem is where we sometimes want to immediately access a file that has been queued for upload- regardless of whether the upload has finished (or even started).
Some of these requests have reasonable workarounds, so the situation isn't dire by any means. However, these workarounds require a harmonious dance between the Storage SDK and our own caching/retry system that, in our opinion, would be better handled entirely within the Storage SDK.
Going forward from here, I'd like to:

Change this issue into a standing feature request for offline / immediate access support (if there is not already an open issue for this) where we can "download" files that have been uploaded from the same device through a cache in the Storage SDK. Optionally, if you would prefer, I could instead close this issue and open a new one for the FR;
Show our interest for the resolution of https://github.com/firebase/firebase-ios-sdk/issues/147;
Request that the Storage SDK documentation be updated to include more specific information about transfer behavior throughout the app session lifecycle (foreground → background → termination → foreground);
Indicate our interest for resumed/restarted uploads on app launch if not already supported (I had a hard time finding a concrete answer, and testing in-app behavior was sometimes inconsistent); and
If our original problem persists, gather more information (such as with the didFinishCollectingMetrics API) and then open a new, more purposeful and specific bug report issue.

Thanks for the detailed update!
I changed this issue to a feature request. Offline support is a pretty popular feature, and we use input like yours to prioritize this feature against work on other products. Unfortunately, this is likely going to be a pretty big undertaking (as we would likely want it to work seamlessly in all feasible scenarios), so any work arounds from your end will likely have to be in place for a while.
I filed a separate issue (internal) to update our documentation - b/174154547

@schmidt-sebastian can you give us an update about this feature request?

@tonyjhuang Any updates?

Hi, we're tracking this feature request internally but unfortunately I don't have an ETA to share at this time.

Hi, we're tracking this feature request internally but unfortunately I don't have an ETA to share at this time.

@tonyjhuang is there any activity on this request?