Always restore cache

Edit: turns out npm ci deletes all the restored cache. This PR means we should decide between the reliability of CI vs the time it takes to bootstrap
We should restore the node_modules cache even if we change package.json. npm install is smart enough to not redo everything from scratch! In this case, however, we should not skip the bootstrap phase completely. It will automatically become faster due to npm's smartness.
This branch is based on #31. Needs rebase and adding it for other platforms for final merging.

Okay, we can try this.
Better to use fallbacks though. Hits the more specific match if it can, then falls back to a more generic/loose match if possible.
Keep everything in the key: field.
Add restoreKeys: for the more generic/looser matches.
https://docs.microsoft.com/en-us/azure/devops/pipelines/release/caching?view=azure-devops#restore-keys

Something like this:
          key: 'npm | "$(Agent.OS)" | "$(buildArch)" | apm/package.json, apm/package-lock.json, script/vsts/platforms/windows.yml'
          restoreKeys: |
             npm | "$(Agent.OS)" | "$(buildArch)" | apm/package.json, apm/package-lock.json
             npm | "$(Agent.OS)" | "$(buildArch)"

Oh and apparently we can cache the "system global npm package cache" somehow, not just the installed node_modules.

Something like this:
          key: 'npm | "$(Agent.OS)" | "$(buildArch)" | apm/package.json, apm/package-lock.json, script/vsts/platforms/windows.yml'
          restoreKeys: |
             npm | "$(Agent.OS)" | "$(buildArch)" | apm/package.json, apm/package-lock.json
             npm | "$(Agent.OS)" | "$(buildArch)"

Oh and apparently we can cache the "system global npm package cache" somehow, not just the installed node_modules.

Done in https://github.com/atom-ide-community/atom/pull/33/commits/b766569979bf04513db55cd51aafaef938212e23

Oh and apparently we can cache the "system global npm package cache" somehow, not just the installed node_modules.
https://stackoverflow.com/questions/14836053/how-can-i-change-the-cache-path-for-npm-or-completely-disable-the-cache-on-win
npm config set cache [some_dir_in_the_working_directory_of_the_pipeline]
If we set this we can cache one more part of CI to run strictly from Azure servers.  (Avoid network calls to npmjs.com).

Done in https://github.com/atom-ide-community/atom/pull/33/commits/b766569979bf04513db55cd51aafaef938212e23

Nice

Oh and apparently we can cache the "system global npm package cache" somehow, not just the installed node_modules.

https://stackoverflow.com/questions/14836053/how-can-i-change-the-cache-path-for-npm-or-completely-disable-the-cache-on-win
npm config set cache [some_dir_in_the_working_directory_of_the_pipeline]
If we set this we can cache one more part of CI to run strictly from Azure servers. (Avoid network calls to npmjs.com).

Where do we need the global npm cache?

We still have cache misses: https://dev.azure.com/atomcommunity/atomcommunity/_build/results?buildId=117&view=logs&j=2985f0af-e798-5fdc-91b8-be9f0a3685c5&t=d0984c8c-0243-5740-7c87-f72756b34e5a&l=36

https://docs.microsoft.com/en-us/azure/devops/pipelines/build/variables?view=azure-devops&tabs=yaml#agent-variables
${{ Agent.BuildDirectory }}/npmcache?
(Sorry if this is off or a bit wrong, haven't tried it yet).

We still have cache misses

Maybe the new runs will upload their caches as the strict identifier AND the loose identifiers. So we might have plenty of chances to hit cache going forward.
By the way, we should make sure it still bootstraps after an inexact cache hit, right?
I think we are already set to do that, because cacheHitVar will be set to inexact, not true. (Bootstrap only skips if all three cache hit vars resolve to true).

I removed bootstrap skipping in https://github.com/atom-ide-community/atom/pull/33/commits/6413b1591f491cc044776c06223cad99734be80b.

If we get an exact cache restore, we do want to skip bootstrapping IMO.
It would be a plain win to revert that, IMO. Bootstrap skipping is nice.

If we get an exact cache restore for all three, then we do want to skip bootstrapping IMO.
It would be a plain win to revert that, IMO. Bootstrap skipping is nice.
It only skips when all three are perfectly exactly matched.

OK. I reverted that.

Maybe we can cache Windows build tools and dependencies... I'm just afraid we're going to have nothing but 39 cache steps pretty soon.

Maybe we can cache Windows build tools and dependencies... I'm just afraid we're going to have nothing but 39 cache steps pretty soon.

Those don't take much time. I prefer caching for something that takes a lot of time. If we could write the cache steps in a more compact way, we could try that.

I just realized we haven't run the PR pipeline on master in... a very long time. So there is no cache saved for master branch. Which drastically reduced the chance of a cache hit.
I think we should manually run the PR Pipeline for master branch every time we merge something that touches a file in script/vsts/platforms/*.yml

@DeeDeeG We can set a pull request trigger for the master branch. That should be possible in Azure UI.

@aminya yes, but it should also be possible in the yaml if you prefer.  Might be a bit different, but that seems about right.

I would like to look at caching the npm package cache, because "why not?"
Something like:
- task: Cache@2 [restore the npm package cache here]
- script:
  npm config set cache $(Agent.BuildDirectory)/CI_npmcache
  [do "npm install" here]

Should it be in a separate PR if I get it working?

Should it be in a separate PR if I get it working?

OK Sure, Make a PR to this branch (always_restore_cache). We can see if it speeds up the things.

Here it is: https://github.com/atom-ide-community/atom/pull/43

For the historical record: to the best of my knowledge, this PR was at commit https://github.com/atom-ide-community/atom/commit/e1929b3a882f294c837b4cf75b1e2263e60b9dfe before #46 was merged into master, and before this PR was then rebased on top of master again.
For convenience (and to keep that commit and its parents from being pruned), this branch exists to mark said commit, at least for now: pr-33-before-pr-46

@DeeDeeG So are you sure that if we change package.json, the bootstrap step is not skipped here?

@DeeDeeG bump

Looking into it to get the proper, exact answer. I have forgotten the detail since this was last brought up.

Off-topic:
While doing the research to give you a solid answer here, I came across this, which seems weird and is probably a bad idea.
https://github.com/atom/atom/blob/09e4af2d99f0c488face9888af6dde602d95e344/script/bootstrap#L35-L36
Modifying the PATH to remove MSBUILD.exe? Why?? I don't think this is a good idea.
One of 212 (!!!) commits in this massive refactoring PR with multiple authors: https://github.com/atom/atom/pull/12410
No real explanation is given in the PR that I could see at a glance, though the comments/commits there are many. I'd like to see if deleting this helps with #44.

The PR is made by the main author of Atom. I can't complain. 😄
I think the reason is to prevent MSBuild to build the native apps.

@DeeDeeG So are you sure that if we change package.json, the bootstrap step is not skipped here?

Yes. It will be an "inexact cache hit"; Even just one "inexact" or missed cache restore is enough to trigger bootstrapping.

Full technical breakdown of what's going to happen with caching/bootstrapping:
If we change [repo_root]/package[-lock].json, apm/package[-lock].json, or script/package[-lock].json, then bootstrapping still happens.
This line is the condition for if bootstrapping will happen. Bootstrapping will happen unless all three caches (all three node_modules folders) were restored with an exact match. [1] [2]
https://github.com/atom-ide-community/atom/blob/09e4af2d99f0c488face9888af6dde602d95e344/script/vsts/platforms/templates/bootstrap.yml#L31
If there were any missed or "inexact" cache restores, any node_modules folders that were able to be restored are there when bootstrapping begins. (You could have apm/node_modules but no script/node_modules, for example.)
Then, there is a check that the "dependency fingerprint" recorded in [repo_root]/node_modules/.dependencies-fingerprint (possibly restored from cache) matches your current repo/machine on the following details:

Minor version component of Electron (electronVersion) in [repo_root]/package.json
Version string of atom-package-manager dependency in apm/package.json
Operating system
Currently running version of Node
CPU architecture / "arch"

If this check fails, all the cache-restored node_modules folders are cleaned away (deleted) and bootstrap happens fresh.
https://github.com/atom-ide-community/atom/blob/09e4af2d99f0c488face9888af6dde602d95e344/script/bootstrap#L31-L33
(Total cleaning like this will only happen if a [repo_root]/node_modules/.dependencies-fingerprint file is found, and happens to be "outdated"/not a match per the above set of details. So, if [repo_root]/node_modules has been restored AND Electron was updated, or CI's Node version was updated, or the bundled apm version string was updated. Otherwise, cache-restored node_modules folders will NOT be cleaned before bootstrapping.)
Thankfully, script/node_modules will always be cleanly installed if boostrapping happens, due to the ci command...
https://github.com/atom-ide-community/atom/blob/09e4af2d99f0c488face9888af6dde602d95e344/script/lib/install-script-dependencies.js#L13
But in that case, restoring it when either of the other two caches was missed or "inexact" is totally pointless. It will be restored, then cleaned and reinstalled with npm ci.
I am concerned that apm's native modules won't be rebuilt, since it isn't installed with npm ci, but rather npm install.
https://github.com/atom-ide-community/atom/blob/09e4af2d99f0c488face9888af6dde602d95e344/script/lib/install-apm.js#L9-L12
In my experience, an existing apm installation doesn't get its native code rebuilt if you do npm install in the apm/ directory.
But then when apm is used to build core packages, the apm ci command is used, so those do get rebuilt again.
https://github.com/atom-ide-community/atom/blob/09e4af2d99f0c488face9888af6dde602d95e344/script/lib/run-apm-install.js#L14
Again, since ci is being used, restoring the [repo_root]/node_modules directory is also a waste of time if either of the other two caches is missed or "inexact". Restoring, deleting and reinstalling is slower than just fresh installing.

I want to think through if there is a reasonable way to add conditional cache restores based on other cache hits being exact. So that we don't restore a cache just to have npm ci delete everything we restored and reinstall it over again.
I'm also somewhat concerned we can have a situation where CI is stuck with a stale cached install of apm that won't be rebuilt. This could lead to errors like this:
Error: The module '/tidee/tidee-au/packages/tidee-au-server/node_modules/bcrypt/lib/binding/bcrypt_lib.node'
was compiled against a different Node.js version using
NODE_MODULE_VERSION 51. This version of Node.js requires
NODE_MODULE_VERSION 57. Please try re-compiling or re-installing

Or other subtle behavior differences of apm.
Generally want to think over and confirm this approach isn't counter-productive and ultimately could even be slower. I'm not sure yet.

Here is a list of possible outcomes when there are inexact cache hits, or cache misses:
List of possible outcomes
All Exact Hits
st at mt == skip bootstrapping ✅
One or more inexact cache hits (no cache misses)
st ai mt == re-run, scripts restore-wipe-reinstalled ❌, apm inexact and not rebuilt ❌, main restore-wipe-reinstalled ❌
st at mi == re-run, scripts restore-wipe-reinstalled ❌, apm exact and not rebuilt ❌, main restore-wipe-reinstalled ❌
st ai mi == re-run, scripts restore-wipe-reinstalled ❌, apm inexact and not rebuilt ❌, main restore-wipe-reinstalled ❌
si at mt == re-run, scripts restore-wipe-reinstalled ❌, apm exact and not rebuilt ❌, main restore-wipe-reinstalled ❌
si ai mt == re-run, scripts restore-wipe-reinstalled ❌, apm inexact and not rebuilt ❌, main restore-wipe-reinstalled ❌
si at mi == re-run, scripts restore-wipe-reinstalled ❌, apm exact and not rebuilt ❌, main restore-wipe-reinstalled ❌
si ai mi == re-run, scripts restore-wipe-reinstalled ❌, apm inexact and not rebuilt ❌, main restore-wipe-reinstalled ❌
One or more cache misses (no inexact cache hits)
st am mt == re-run, scripts restore-wipe-reinstalled ❌, apm installed fresh ✅, main restore-wipe-reinstalled ❌
st at mm == re-run, scripts restore-wipe-reinstalled ❌, apm exact and not rebuilt ❌, main installed fresh ✅
st am mm == re-run, scripts restore-wipe-reinstalled ❌, apm installed fresh ✅, main installed fresh ✅
sm at mt == re-run, scripts installed fresh ✅, apm exact and not rebuilt ❌, main restore-wipe-reinstalled ❌
sm am mt == re-run, scripts installed fresh ✅, apm installed fresh ✅, main restore-wipe-reinstalled ❌
sm at mm == re-run, scripts installed fresh ✅, apm exact and not rebuilt ❌, main installed fresh ✅
Three cache misses
sm am mm == re-run, scripts installed fresh ✅, apm installed fresh ✅, main installed fresh ✅ (This is a standard clean bootstrap)
Combination of cache misses and inexact cache hits
One inexact cache hit, one or two cache misses
si at mm == re-run, scripts restore-wipe-reinstalled ❌, apm exact and not rebuilt ❌, main installed fresh ✅
si am mt == re-run, scripts restore-wipe-reinstalled ❌, apm installed fresh ✅, main restore-wipe-reinstalled ❌
si am mm == re-run, scripts restore-wipe-reinstalled ❌, apm installed fresh ✅, main installed fresh ✅
st ai mm == re-run, scripts restore-wipe-reinstalled ❌, apm inexact and not rebuilt ❌, main installed fresh ✅
sm ai mt == re-run, scripts installed fresh ✅, apm inexact and not rebuilt ❌, main restore-wipe-reinstalled ❌
sm ai mm == re-run, scripts installed fresh ✅, apm inexact and not rebuilt ❌, main installed fresh ✅
st am mi == re-run, scripts restore-wipe-reinstalled ❌, apm installed fresh ✅, main restore-wipe-reinstalled ❌
sm at mi == re-run, scripts installed fresh ✅, apm exact and not rebuilt ❌, main restore-wipe-reinstalled ❌
sm am mi == re-run, scripts installed fresh ✅, apm installed fresh ✅, main restore-wipe-reinstalled ❌
Two inexact hits, one cache miss
si ai mm == re-run, scripts restore-wipe-reinstalled ❌, apm inexact and not rebuilt ❌, main installed fresh ✅
si am mi == re-run, scripts restore-wipe-reinstalled ❌, apm installed fresh ✅, main restore-wipe-reinstalled ❌
sm ai mi == re-run, scripts installed fresh ✅, apm inexact and not rebuilt ❌, main restore-wipe-reinstalled ❌

s[?] means the script/node_modules directory cache
a[?] means the apm/node_modules directory cache
m[?] means the "main" or [repo_root]/node_modules directory cache.
[?]t means "true" or exact cache hit.
[?]i means "inexact"; an inexact cache hit
[?]m means "miss"; a cache miss

As that list of possibilities shows, allowing any inexact cache hits has a downside. Due to fairly consistent use of npm ci in the bootstrap script in a CI environment, any inexact restored cache is simply wiped out before being reinstalled clean. Thus, restoring the [repo_root]/node_modules or script/node_modules caches are a waste of time if any cache is missed or inexact.
We can "solve" this by allowing bootstrapping to be skipped if all three caches are restored, regardless of if they were exact or inexact. Currently only three exact cache hits will skip bootstrapping. The downside: How will we know if stale dependencies are causing our CI failures? How will we have confidence in the results? How will we debug anything?
In any case, this restoreKey makes no sense: npm | "$(Agent.OS)" | "$(BUILD_ARCH)". If there is an outdated package.json or package-lock.json, there is no reason to restore the cache. Either it is wiped away by npm ci, or we have restored incorrect dependencies and are going to use them in the final build/test.
npm ci isn't used with apm right now, because it seems to conflict with the "dedupe" postinstall script that the atom-package-manager package runs right after being installed. This means restored apm caches aren't wiped out, so perhaps the cache restore isn't a waste of time here... but that could be a problem with inexact cache restores, as native code is not rebuilt when running a simple npm install in a directory where the packages have already  been installed to node_modules. Allowing inexact restore of apm/node_modules might mean we error out with a "wrong node version" error. Or other related, but subtler wrong behavior.

By the way, even without this PR, a cache miss for any of the three caches can make our CI inefficient.
If script/node_modules cache is missed, then any restored [repo_root]/node_modules will be wiped out by apm ci. So restoring was wasted time.
If [repo_root]/node_modules cache is missed, then any restored script/node_modules cache will be wiped out by npm ci.
If the apm/node_modules cache is missed, either of the other two caches that might have been restored will be wiped out by npm ci/apm ci.
This is why I like SaveCache@1. It either "just works" (clean restore of all three caches), or it gets out of the way. The complexity and room for footguns is pretty high the way we are trying to use Cache@2.

I will review your comments later, but if you are missing something from Cache2, you can make a PR:
https://github.com/microsoft/azure-pipelines-tasks/blob/master/Tasks/CacheV2/task.json

apm ci and npm ci deletes node_modules intentionally before it does anyhting else. For reliability and reproducibility.
It was enough of a serious concern for the npm devs that they did this deliberately.
I am honestly surprised you don't feel similarly about reliability and reproducibility. We are exposing ourselves to what is essentially undefined behavior, to borrow a programming term. Sure, maybe it works and it's fast... Until it doesn't work, in the most confusing way possible, and then debugging it takes a day and a portion of your sanity.

The time here is spent on building the native modules. Try running apm install in an already bootstrapped repository. It finishes almost instantly.
In the docs, it says it is because some of the user-oriented features are disabled. That means we can get similar performance boost by doing:
npm set progress=false
npm install --no-audit --only=production

The time here is spent on building the native modules

I can agree that is true.

In the docs, it says it is because some of the user-oriented features are disabled. That means we can get similar performance boost by doing
npm set progress=false
npm install --no-audit

Can you do a "control test" with auditing and progress messages enabled?
(About why ci is fast, if/when it is: If I understand correctly, most of npm ci's performance gains are from not having to reason about the state of node_modules and do filesystem checks to gather that info, and compare it to package-lock.json and package.json.)
In any case, the reliability and stability gains cannot be replicated without deleting node_modules and starting over. If we install newer apm, we probably should be rebuilding the main packages from scratch, for example.
Not everything is about squeezing out the fastest completion time. Not having to think about whether your CI did something invalid is really important.

Can you do a "control test" for npm install, with auditing and progress messages enabled? How much slower is that? (I just tried something like this, and it only added about .4 seconds to have auditing and progress messages).

It is about 2s here.

We can get fairly optimal combination of reliability and speed by doing npm install && npm rebuild instead of npm ci, if we want to restore and use slightly stale state of node_modules. But sadly that only saves on fetch/install time vs npm ci, which is already pretty fast. It still rebuilds native packages, which you pointed out is the slowest part.
By the way, bootstrapping is MUCH FASTER than testing. It is about 5 minutes on Linux, 6-8 minutes on macOS, 10 or 12 minutes on Windows.
And the slower platforms pretty much ALWAYS save a cache after the build job succeeds, so the "test runner" jobs can restore with that and avoid bootstrapping altogether.

(About why ci is fast, if/when it is: If I understand correctly, most of npm ci's performance gains are from not having to reason about the state of node_modules and do filesystem checks to gather that info, and compare it to package-lock.json and package.json. Those checks are there to reduce network/local cache hits. But skipping all those checks is ultimately faster.)

I do not think it is a good idea to use npm ci. I did not know that it deletes everything. Building everything from scratch is the worst idea.

In any case, the reliability and stability gains cannot be replicated without deleting node_modules and starting over. If we install newer apm, we probably should be rebuilding the main packages from scratch, for example.
Not everything is about squeezing out the fastest completion time. Not having to think about whether your CI did something invalid is really important.

I prefer to reuse a good working cache that works instead of building every time from scratch and rely on the CI env to build it correctly 😄. npm install is not evil. I have not seen it mess up so far.

npm install && npm rebuild

I think this is overkill. Why bother to rebuild? npm install is smart enough to build things when versions change. I do not understand the reason for rebuild.

The problem is, we can and do update Node in CI from time to time. And if we aren't careful, there will be restored native code that its built against an older major version of Node. Then erroring out and CI fails. And we have to manually intervene to make a new cache silo for that PR so it passes, etc.
apm is installed by the npm bundled in script/node_modules/.bin/npm. Main packages are built by apm. It's all interdependent. Restoring one or two of them is a lot of permutations we have to be sure all work.
We can figure that out correctly now, or scratch our heads later in the middle of other important work. Better to figure it out in ahead of time.

The problem is, we can and do update Node in CI from time to time. And if we aren't careful, there will be restored native code that its built against an older major version of Node. Then erroring out and CI fails. And we have to manually intervene to make a new cache silo for that PR so it passes, etc.

We can store the used Node version somewhere and write a simple CI script to rebuild if the Node version has changed.

See this as a starting point:
https://github.com/atom/atom/blob/4a9d56f52cab00a22744858d4077600d5365197a/script/bootstrap#L31-L33
https://github.com/atom/atom/blob/4a9d56f52cab00a22744858d4077600d5365197a/script/lib/dependencies-fingerprint.js
This currently assumes that [repo_root]/node_modules has been installed or restored already, or it doesn't work.

I suppose we could check in the Node version that CI uses to build, like we do with electronVersion in package.json. That seems a lot easier, more reliable, and less complicated IMO.

Looking at the performance of npm install and npm ci:
npm install (fresh install with no node_modules present): ~115-130 seconds
npm ci: ~90 seconds
npm install with node_modules present (no changed dependencies): ~12-15 seconds
npm install with `node_modules present (one changed dependency with no native code to build): ~17-21 seconds
(Tested in script/ on Ubuntu.)
Time to restore cache for script/node_modules in CI (macOS): ~25-27 seconds

npm ci: ~90 seconds
npm install with node_modules present (no changed dependencies): ~12-15 seconds
npm install with node_modules present (one changed dependency with no native code to build): ~17-21 seconds

npm install with cache is at least 3 times faster

If restoring the cache helps in bootstrapping or building even if they are executed, we can reconsider this pull request again. But it seems that bootstrap uses npm ci which counteracts performance gains we could get from this pull request.

We should add all the scripts that affect the cache to the keys. I want to keep that for a separate pull request.

Whoops. I'm trying something on my own personal fork. Accidentally pushed here...
https://dev.azure.com/DeeDeeG/b/_build/results?buildId=214&view=results
https://github.com/DeeDeeG/atom/commits/always_restore_cache

Would be nice to have #68 on this branch (rebase on master or merge master in to here). So we can run a lot of CI runs more quickly.

@DeeDeeG Thanks for the changes. This is in going in the right way know. Previously, it was not that useful! I want to see how these changes affect the speed though.

My branch at my fork is rebased on master. @aminya If you don't mind I'd push the rebased version here, since it seems to be in pretty good shape.

I updated this branch form master. But no problem if you need that.

It's a habit I have. Makes it easier to see what I did and know ahead of time it works when merged to master. And I may have mentioned but I just like rebasing! I'll double-check it's working and push here.
Some commits ended up empty, so I dropped them by the way.

I suspect apm isn't passing the --no-save flag on to npm... So there is no way to avoid bumping the version in package-lock.json, which then changes the cache key, causing an inexact cache hit, and foiling the "skip bootstrap" condition.
Two solutions:

patch apm so it passes the --no-save flag on to npm.

(I've done something like this before. I'd like to do this, because as I mentioned, upstream's bot bumps the "version" in package.json often without updating the "version" in package-lock.json. I admit patching apm just to fix this is a bit overkill, but it also prevents the cache key from being changed in other situations, so it could be worth it. Hmm :thinking: .)

Just add a commit to master that bumps the "version" in [repo_root]/package-lock.json appropriately.

What's the news on this PR? It is inactive for some time....


[FLINK-12844][table-planner-blink] Use default conversion class LocalDate/LocalTime/LocalDateTime for DateType/TimeType/TimestampType in blink

What is the purpose of the change
Now we still use java.sql.Timestamp to be default conversion class for TimestampType.
We should use design of new Type System to use java.time.Local***.
NOTE, This may affect user behaviour:
eg: UDF with eval(Object o), now will pass a java.time.Local*** instead of java.sql..
Compatibility method: use DataType.bridgedTo(java.sql..class);
Verifying this change
ut
Does this pull request potentially affect one of the following parts:

Dependencies (does it add or upgrade a dependency): (no)
The public API, i.e., is any changed class annotated with @Public(Evolving): (no)
The serializers: (no)
The runtime per-record code paths (performance sensitive): (no)
Anything that affects deployment or recovery: JobManager (and its components), Checkpointing, Yarn/Mesos, ZooKeeper: (no)
The S3 file system connector: (no)

Documentation

Does this pull request introduce a new feature? (no)

This PR is rebased on https://github.com/apache/flink/pull/8757

@wuchong @KurtYoung Updated, PTAL


fix: remove required expo root from app json file

Linked issue
Fixes #56

:tada: This PR is included in version 0.7.4 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


hon2a/eslint-optional

The es_lint initializer is now optional. This allows the application to use the latest ESLint and plugins without incompatibilities with Quadro, preventing errors as this one.
Personally I think the es_lint initializer should never have been created, because it's of no concern to the framework, but that applies to a lot of things in here.

@hon2a
Is new version of eslint is not compatible with the version that being used here? Can we just upgrade the version in quadro? I would suggest upgrading so that other services can make use of latest features too.
If things are very-very urgent you can always go through the git url route for your branch and move to specific version when the code is merged.
Quadro is  framework and also act as a chassis to all our micro-service. Idea is reusability, simplicity  and standardization of micro services. Feel free to open issues if you feel like there are things here that should not be part of this framework. Any contribution that improves this framework is highly appreciated.
Also here are steps for contribution

Open a issue
Create a pull request against that issue
Make sure you have a test case
Update the change log and the version

#265 - here's a pro forma issue

Turns out that turning initializers off individually through config is already possible and I just didn't know about it. Too bad we were discussing general process and not the one line of code in the patch :)


Port formal specification to Agda

We shall port the formal specification of the Consensus Layer to Agda.

We also recently started hiding field and constructor X in record definitions in the ledger spec as they are somewhat confusing to non-Agda people (e.g. I've gotten the question 'what does "field" mean?') and they don't really add much.

Fixed in 72bd2dd5f9364d7e8afdbd8529480074a5c2ac80. Note that, in order to achieve the desired layout, I chose to use a combination of AgdaAlign and AgdaSuppressSpace instead of AgdaMultiCode since the latter removes additional line breaks that should not be removed.

FTR: In addition to the review, the following tasks are still pending:

[ ] Fix the Nix-related issues (@amesgen)
[ ] Add a link to the document on the website (@IntersectMBO/ouroboros-consensus)


How to disable .img and only allow it in certain channels.

Hello I am trying to disable the command .img. People keep spamming images in the lounge area and we have specific areas for images.
I have created the Nadeko role and added it to myself.

I figured it out....
.sm Searches disable
.cm Searches enable #ExampleChannel

@JoshB84  Please mark this issue as closed :-)


Support tracking the message listener of spring jms

[ ] If this pull request closes/resolves/fixes an existing issue, replace the issue number. Closes #.
[x] Update the CHANGES log.

I recommited the code and successfully passed the github action job

Your test scenarios failed. Please test them locally, make sure they are passed and stable.

Why did you removr 5.0?

Why did you remove 5.0?

5.0 spring version too low lead to test scenarios failed

My question is about why. We should be clear about supported versions.
5.x should cover 5.0.
Could you check the codes and explain why?

My question is about why. We should be clear about supported versions. 5.x should cover 5.0.
Could you check the codes and explain why?

The plugin can support 5.0, but I'm still figuring out how to make it pass the test scenario

Take your time. We should cover all 5.x versions.

Any update? I am planning to cut the 9.3.0 release

Please resolve the conflicts.

What happened here?

What happened here?

I thought you didn't need this plugin.

What happened here?

I removed the context carrier and replaced it with context snapshot. Is that right?

I am waiting for your reply about why do header extra when you only create local span. This is rare from my understanding.

I am waiting for your reply about why do header extra when you only create local span. This is rare from my understanding.

I hope to trace specific execute of the active MQ consumers.

But it is pointless when you have another header extracring from entry span from the actual entry span.
Local span doesn't need reference of the producer.

But it is pointless when you have another header extracring from entry span from the actual entry span.
Local span doesn't need reference of the producer.

Yes, after your reminder, I realized this mistake.
I did this before because if I use context snapshot to connect to consumers, I also need to enhance the active MQ message.
So, this plugin doesn't need to do anything except create a local span?

If that could make the trace continues as your expectations, then yes.

The jms connectionFactory is very troublesome to obtain the MQ_BROKER Tag

Can only be used by hard coding

I think active MQ should be updated to put correct tag value in JMS case.

I have studied the support of several major mqs for jms and how to integrate them. In most scenarios, only ActiveMQ uses JMS, so writing a general plug-in to support JMS seems a bit costly. If you need to use JMS, writing a plug-in with hard coding is the best way.

should create plugin project spring-jms-activemq-5.x-plugin

Agree for that. Feel free to update.

should create plugin project spring-jms-activemq-5.x-plugin spring-jms-rabbitmq-5.x-plugin .... like this

Thank you for your recommend.
But i have no idea about this, do you have any plans?

No, Java agent nowadays is totally relying on volunteers.
I don't touch on codes, especially plugins, for years.

No, Java agent nowadays is totally relying on volunteers. I don't touch on codes, especially plugins, for years.

Yes, i know :)
I asked @cloudgc

i write demo project
https://github.com/cloudgc/apm-spring-jms
already applied to actual company projects
If you need it urgently, you can fork from it, I will consider adding this plug-in later.

Close for now. Discussion could continue.
If either of you wants to add the new one, send a new pull request.

Close for now. Discussion could continue. If either of you wants to add the new one, send a new pull request.

Agree, thank you for your guidance. @wu-sheng

i write demo project
https://github.com/cloudgc/apm-spring-jms
already applied to actual company projects
If you need it urgently, you can fork from it, I will consider adding this plug-in later.

I have viewed your demo, and it cloud work together with the activemq-5.x-plugin to create duplicate consumer entry spans. @cloudgc

There is indeed a problem

This is the call graph. I will think of a friendly way to fix it.

i write demo project

https://github.com/cloudgc/apm-spring-jms

already applied to actual company projects

If you need it urgently, you can fork from it, I will consider adding this plug-in later.

I have viewed your demo, and it cloud work together with the activemq-5.x-plugin to create duplicate consumer entry spans. @cloudgc

What do you mean duplicate? Does it leverage the nested entry span mechanism? Which make only the first entry span left.
Is that what you mean?

I don't think that, the demo projcet will create a new entry span link through ActiveMQ producer span, this repeats with ActiveMQ consumer.
The process of use spring JMS & third-party MQ would be like:
-> create connectionFactory(take ActiveMQ for example)
-> JMS send message
-> MQ client create message(the activemq plugin is working, create producer entry span)
-> JMS listener
-> MQ client consume message(the activemq plugin is working, create consumer entry span)
-> JMS listener execute(the activemq plugin lost trace)

he final effect is as follows:

activemq-consumer entry was stop when over dequeue method
so there must be a new span at the same level with MQ-consumer Span

the final effect is as follows:
activemq-consumer entry was stop when over dequeue method so there must be a new span at the same level with MQ-consumer Span
and i fix my demo : apm-spring-jms

I have discussed with @wu-sheng, and create two entry spans in the consumer part, which will cause the consumer traffic to be counted twice.
So far, i think the better way is to update the active MQ plugin, and generate a context snapshot when creating messages, the spring JMS plugin create a local span, if message has a context snapshot, it will be linked.

should be , not only activemq needs to do this, other mq queues need create  context snapshot ， looking forward to your code changes


Fix #105: only use one test runner for results, even if multiple streams are created

Fixes https://github.com/substack/tape/issues/105

(oh, same fix as https://github.com/substack/tape/pull/361, just with a unit test)

Nice! Seeing as two people have now contributed roughly the same fix to a years old issue, maybe we'll get it fixed soon :-)  (CC @ljharb )


PHP: composer install returns segmentation fault when using php-ZTS and ext-grpc v1.20.0

What version of gRPC and what language are you using?

PHP grpc extension v1.20.0

What operating system (Linux, Windows,...) and version?

Alpine Linux

What runtime / compiler are you using (e.g. python version or version of gcc)

PHP 7.3.5 (cli) (built: May  4 2019 01:11:17) ( ZTS )

What did you do?
The composer install command fails with grpc v1.20.0.
Here is Dockerfile for reproduction.
FROM php:7-zts-alpine

RUN apk add --no-cache --virtual=.build-deps zlib-dev autoconf gcc g++ make \
  && pecl install grpc-1.20.0 \
  && docker-php-ext-enable grpc \
  && apk del .build-deps \
  && apk del *-dev

COPY --from=composer:latest /usr/bin/composer /usr/bin/composer

WORKDIR /src

COPY composer.json /src/composer.json
COPY composer.lock /src/composer.lock
ENV COMPOSER_ALLOW_SUPERUSER 1
RUN composer install --no-scripts --no-autoloader

$ docker build -t zts-grpc-1-20-0 .
Sending build context to Docker daemon  30.72kB
Step 1/8 : FROM php:7-zts-alpine
 ---> e71bb5cd1cb5
Step 2/8 : RUN apk add --no-cache --virtual=.build-deps zlib-dev autoconf gcc g++ make   && pecl install grpc-1.20.0   && docker-php-ext-enable grpc   && apk del .build-deps   && apk del *-dev
 ---> Using cache
 ---> bb680bd34f02
Step 3/8 : COPY --from=composer:latest /usr/bin/composer /usr/bin/composer
 ---> Using cache
 ---> 81ef06ad6d72
Step 4/8 : WORKDIR /src
 ---> Using cache
 ---> 37906c26168d
Step 5/8 : COPY composer.json /src/composer.json
 ---> Using cache
 ---> df9f45378fac
Step 6/8 : COPY composer.lock /src/composer.lock
 ---> Using cache
 ---> 9f974cc1cabb
Step 7/8 : ENV COMPOSER_ALLOW_SUPERUSER 1
 ---> Using cache
 ---> 52dd37811396
Step 8/8 : RUN composer install --no-scripts --no-autoloader
 ---> Running in f65e3821f46b
Loading composer repositories with package information
Installing dependencies (including require-dev) from lock file
Nothing to install or update
The command '/bin/sh -c composer install --no-scripts --no-autoloader' returned a non-zero code: 139

However, using v1.19.0 succeeded.
-  && pecl install grpc-1.20.0 \
+  && pecl install grpc-1.19.0 \

$ docker build -t zts-grpc-1-19-0 .
Sending build context to Docker daemon  30.72kB
Step 1/8 : FROM php:7-zts-alpine
 ---> e71bb5cd1cb5
Step 2/8 : RUN apk add --no-cache --virtual=.build-deps zlib-dev autoconf gcc g++ make   && pecl install grpc-1.19.0   && docker-php-ext-enable grpc   && apk del .build-deps   && apk del *-dev
 ---> Using cache
 ---> cd5c691e1dd3
Step 3/8 : COPY --from=composer:latest /usr/bin/composer /usr/bin/composer
 ---> Using cache
 ---> d802f4850cdf
Step 4/8 : WORKDIR /src
 ---> Using cache
 ---> 8516eb3d0019
Step 5/8 : COPY composer.json /src/composer.json
 ---> Using cache
 ---> b1face39853f
Step 6/8 : COPY composer.lock /src/composer.lock
 ---> Using cache
 ---> f31668415a0c
Step 7/8 : ENV COMPOSER_ALLOW_SUPERUSER 1
 ---> Using cache
 ---> 0c3197d024e1
Step 8/8 : RUN composer install --no-scripts --no-autoloader
 ---> Using cache
 ---> abf069554601
Successfully built abf069554601
Successfully tagged zts-grpc-1-19-0:latest

An additional information is the core dump's stack trace.
#0  grpc_completion_queue_shutdown (cq=0x0) at /tmp/pear/temp/grpc/src/core/lib/surface/completion_queue.cc:1373
#1  0x00007fad18f6e900 in grpc_php_shutdown_completion_queue () at /tmp/pear/temp/grpc/src/php/ext/grpc/completion_queue.c:28
#2  0x00007fad18f6ef1a in zm_shutdown_grpc (type=<optimized out>, module_number=<optimized out>) at /tmp/pear/temp/grpc/src/php/ext/grpc/php_grpc.c:370
#3  zm_shutdown_grpc (type=<optimized out>, module_number=<optimized out>) at /tmp/pear/temp/grpc/src/php/ext/grpc/php_grpc.c:360

Dupe of #18895

This is obviously not a dupe of #18895 which is about the build, this one is about a runtime segfault with PHP 7
indeed it seems this extension doesn't support ZTS at all
perhaps simpler to disallow ZTS build

Keeping this open until I made a bugfix release for it and verified.

This should be fixed with the 1.21.3 release.


How to use this extension to integarte with Twilio API for 2FA OTP

Is there anyway to use this extension with twilio 2FA OTP in burp suite professional for authenticated scan.

Apologies for the late response. If you're using Burp Suite Professional, I'd recommend using the BApp Store extension, Google Authenticator over this extension. This extension is more difficult to configure, as it is designed to be used with Burp Suite Enterprise Edition.


[1.9.x] Fixed #26806 -- Fixed triple quoted

https://code.djangoproject.com/ticket/26806

Merged in 2032bcf18280a875a59a39cf85c226da0a310d11, thanks.
For future reference, please send the pull request to the master branch. The committer will backport as needed.


Proposal: support new request to writer

It will be more easy to migrate from code like io.Copy(writer, resp.Body) to grab if grab supports new download to an opened writer.
grab.NewRequestToWriter(writer io.Writer, url string)

@gonejack @cellargalaxy check this out. I just added support for grab.NewRequestToWriter.
https://github.com/opensaucerer/grab#this-extended-version-of-the-original-cavaliergophergrab-now-allows-you-to-download-files-into-a-given-iowriter


[Bug] rundev.sh errors

Running the rundev.sh on bash fails as it is trying to set environment variables with hyphens (-) in.
As per http://pubs.opengroup.org/onlinepubs/000095399/basedefs/xbd_chap08.html, this is not allowed:

Environment variable names used by the utilities in the Shell and Utilities volume of IEEE Std 1003.1-2001 consist solely of uppercase letters, digits, and the '_' (underscore) from the characters defined in Portable Character Set and do not begin with a digit. Other characters may be permitted by an implementation; applications shall tolerate the presence of such names. Uppercase and lowercase letters shall retain their unique identities and shall not be folded together. The name space of environment variable names containing lowercase letters is reserved for applications. Applications can define any environment variables with names from this name space without modifying the behavior of the standard utilities.

Initial thought to solve is to change the client ids (used for integration tests):

change in integration tests
change in rundev.ps1 and rundev.sh
change in ARM template
change in VS launch settings

Resolved with #303


Correctly report results from Testing Farm

Previously, if there were multiple TF jobs differentiated by their
identifier, Steve would create a celery task for each of the jobs,
regardless of their identifier for the single results event. To overcome
this, save the identifier in the DB and obtain it when a result arrives.
Check for identifier match when creating celery tasks based on jobs.
TODO:

[x] Write new tests or update the old ones to cover new functionality.
[x] Update doc-strings where appropriate.

Fixes #1535 (or at least I hope, will need to be verified on stg, I have a simple reproducer https://github.com/FrNecas/packit-reproducer/pull/1 )

RELEASE NOTES BEGIN
Results from Testing Farm are now correctly reported when multiple jobs with different identifier are defined.
RELEASE NOTES END

recheck

recheck


Extensions for gateway

What would you like to be added:
Add Extension API for gateway.
Why this is needed:
Optimize ease of use, flexibility and scalability.
Now every gateway implement has its own unique features while Kubernetes Gateway API cannot cover them.
It is ok that users use Gateway API + specific gateway API, but would be better if only use Gateway API.
In addition to ease of use issues, more flexibility would be introduced by Extension API. As we know, bring a new feature into Gateway API usually speed much time, During this time, Extension API can help as well.
Full design is as https://docs.google.com/document/d/1FjUEKtpymVrY0xAyZVz1nnVB1fryHU7s9XWE6C3Bsww/edit?usp=sharing

@daixiang0 Gateway API already supports extending the API using PolicyAttachments https://gateway-api.sigs.k8s.io/geps/gep-713/

I knew it but it can not support some features like this feature in Kong.
Those features are not in policy field but implemented in the gateway.

The gateway can define its own policy. For example, HTNN defines the FilterPolicy to run plugins: https://github.com/mosn/htnn/blob/main/site/content/en/docs/concept/filterpolicy.md

The gateway can define its own policy. For example, HTNN defines the FilterPolicy to run plugins: https://github.com/mosn/htnn/blob/main/site/content/en/docs/concept/filterpolicy.md

I am confused about those belongs, now we have GEP, but for example, HTNN still use htnn.mosn.io not gateway.networking.k8s.io, I can't think it followed GEP standard from its YAML statement though in fact it did.


fix(types): fix typescript definition for 'Accordion.Accordion'

Hey,
is my first PR, so if i forgot something... sorry :)!
this commit fix the failure

TS2604:JSX element type 'Accordion.Accordion' does not have any construct or call signatures.

Codecov Report

Merging #2180 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master    #2180   +/-   ##
=======================================
  Coverage   99.76%   99.76%
=======================================
  Files         151      151
  Lines        2606     2606
=======================================
  Hits         2600     2600
  Misses          6        6

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 955ed6e...d8e1db1. Read the comment docs.

Released in<EMAIL_ADDRESS>


trigger force close not working

triggerforceclose not working
command: sudo chantools triggerforceclose --peer 03627ebe50fc6eb80b0caab0c3714958c701eda735e3c29588e83150d6d4a93976@<IP_ADDRESS>:39880 --channel_point 0343cf3d12ed8208aade0c7c3e8b7f5f64256e7175905b2137c2adb077bd849:0
node has tried to close from their end but receives this message: 'They sent ERROR channel 067…: unable to resume channel, recovery required'
receive below response when using above command:
2024-09-17 18:44:49.145 [INF] CHAN: Attempting to connect to peer 03edfc1919ca6fe4de6a6645e544486bf5a651122fdb2172b6c96ce3fb68956d51, dial timeout is 1m0s
2024-09-17 18:44:49.156 [DBG] CHDB: Populating in-memory channel graph, this might take a while...
2024-09-17 18:44:49.157 [DBG] CHDB: Finished populating in-memory channel graph (took 50.034µs, num_node_features=0, num_nodes=0, num_channels=0)
2024-09-17 18:44:49.157 [INF] CHDB: Checking for schema update: latest_version=31, db_version=31
2024-09-17 18:44:49.157 [INF] CHDB: Checking for optional update: prune_revocation_log=false, db_version=empty
2024-09-17 18:44:49.157 [DBG] PEER: Peer(03627ebe50fc6eb80b0caab0c3714958c701eda735e3c29588e83150d6d4a93976): Sending Init to 03627ebe50fc6eb80b0caab0c3714958c701eda735e3c29588e83150d6d4a93976@<IP_ADDRESS>:39880
2024-09-17 18:44:49.294 [DBG] PEER: Peer(03627ebe50fc6eb80b0caab0c3714958c701eda735e3c29588e83150d6d4a93976): Received Init from 03627ebe50fc6eb80b0caab0c3714958c701eda735e3c29588e83150d6d4a93976@<IP_ADDRESS>:39880
2024-09-17 18:44:49.294 [DBG] PEER: Peer(03627ebe50fc6eb80b0caab0c3714958c701eda735e3c29588e83150d6d4a93976): Loaded 0 active channels from database
2024-09-17 18:44:49.294 [INF] CHAN: Connection established to peer 03edfc1919ca6fe4de6a6645e544486bf5a651122fdb2172b6c96ce3fb68956d51
2024-09-17 18:44:49.294 [INF] PEER: Peer(03627ebe50fc6eb80b0caab0c3714958c701eda735e3c29588e83150d6d4a93976): Negotiated chan series queries
2024-09-17 18:44:49.294 [INF] CHAN: Sending channel error message to peer to trigger force close of channel 0343cf3d12ed8208aade0c7c3e8b7f5f64256e7175905b2137c2adb077bd849:0
2024-09-17 18:44:49.294 [DBG] PEER: Peer(03627ebe50fc6eb80b0caab0c3714958c701eda735e3c29588e83150d6d4a93976): Sending Error(type=17) to 03627ebe50fc6eb80b0caab0c3714958c701eda735e3c29588e83150d6d4a93976@<IP_ADDRESS>:39880
2024-09-17 18:44:49.294 [INF] CHAN: Message sent, waiting for force close transaction to appear in mempool
Error: error getting channel address: error decoding data from API 'https://blockstream.info/api/tx/0343cf3d12ed8208aade0c7c3e8b7f5f64256e7175905b2137c2adb077bd849', server might be experiencing temporary issues, try again later; error details: invalid character 'I' looking for beginning of value
Usage:
chantools triggerforceclose [flags]
Examples:
chantools triggerforceclose
--peer 03abce...@xx.yy.zz.aa:9735
--channel_point abcdef01234...:x
Flags:
--apiurl string          API URL to use (must be esplora compatible) (default "https://blockstream.info/api")
--bip39                  read a classic BIP39 seed and passphrase from the terminal instead of asking for lnd seed format or providing the --rootkey flag
--channel_point string   funding transaction outpoint of the channel to trigger the force close of (:)
-h, --help                   help for triggerforceclose
--peer string            remote peer address (@[:])
--rootkey string         BIP32 HD root key of the wallet to use for deriving the identity key; leave empty to prompt for lnd 24 word aezeed
Global Flags:
-r, --regtest   Indicates if regtest parameters should be used
-s, --signet    Indicates if the public signet parameters should be used
-t, --testnet   Indicates if testnet parameters should be used
error getting channel address: error decoding data from API 'https://blockstream.info/api/tx/0343cf3d12ed8208aade0c7c3e8b7f5f64256e7175905b2137c2adb077bd849', server might be experiencing temporary issues, try again later; error details: invalid character 'I' looking for beginning of value

unable to resume channel, recovery required

If your peer cannot manually force close the channel, then trying to trigger the same over the p2p network won't work either. Did they restore from a backup as well?

server might be experiencing temporary issues, try again later; error details:

As the message mentions: the blockstream.info server isn't responding with the expected response. Did you try again later?

yes have been trying for past 2 days

You can check the status manually by looking up the channel funding transaction (0343cf3d12ed8208aade0c7c3e8b7f5f64256e7175905b2137c2adb077bd849) on a block explorer. But it doesn't seem to exist, so the channel never made it to the chain. And since it never confirmed, it also cannot be force closed.
Without more information available, I'd say the funds have already been spent by your node in another transaction.

this is the transaction when channel was opened
https://mempool.space/tx/1752571bafee62e7494686cc2774a372c128fcb2f613e43c72077de83a5c7606

Then you are using the wrong --channel_point argument in your call.

where do i find the correct channel point?

The command seems to work and does what it intends to do. But it's not a guarantee to arrive at the desired result. You're still dependent on the other node to do the right thing (and them actually still having the channel state).
Try it a couple of more times. And if nothing happens, try to contact the peer.

have asked the peer yesterday (after i was sending the correct channel point).
as discussed previously, they are getting this message when they try to close from their side.
"They sent ERROR channel 067...: unable to resume channel, recovery required" and it won't let me do anything with the channel.

Sounds like they also lost some data. You might have to look into a zombie recovery, guide is here: https://github.com/lightninglabs/chantools/blob/master/doc/zombierecovery.md


Reset query after modal close

I want to merge this change because it resets search input value after modal window closing.
Pull Request Checklist

[ ] Privileged views and APIs are guarded by proper permission checks.
[ ] All visible strings are translated with proper context.
[ ] All data-formatting is locale-aware (dates, numbers, and so on).
[ ] Database queries are optimized and the number of queries is constant.
[ ] Database migration files are up to date.
[ ] The changes are tested.
[ ] The code is documented (docstrings, project documentation).
[ ] GraphQL schema and type definitions are up to date.
[x] Changes are mentioned in the changelog.

Here is the report for f8adce64a9f716572e7ec7448dce20e7a8480f57 (mirumee/saleor @ attributes/fix-attribute-assign-form)
Base comparison is e29d12d71a196026a0de19f0861a94db3f2b8fe3.
No differences were found. (click me)

# api.benchmark checkout
  test name                           	left count 	right count	duplicate count
  ------------------------------------	-----------	-----------	---------------
  add billing address to checkout     	         34	         34	             20
  add shipping to checkout            	          7	          7	              0
  checkout payment charge             	         14	         14	              0
  complete checkout                   	          6	          6	              0
  create checkout                     	         43	         43	             21

# api.benchmark homepage
  test name                           	left count 	right count	duplicate count
  ------------------------------------	-----------	-----------	---------------
  retrieve main menu                  	          5	          5	              0
  retrieve product list               	          4	          4	              0
  retrieve secondary menu             	          5	          5	              0
  retrieve shop                       	          2	          2	              0

# api.benchmark product
  test name                           	left count 	right count	duplicate count
  ------------------------------------	-----------	-----------	---------------
  product details                     	         15	         15	              3

# api.benchmark variant
  test name                           	left count 	right count	duplicate count
  ------------------------------------	-----------	-----------	---------------
  retrieve variant list               	         15	         15	              6


Moving recovery(1) resources to v1beta1 version

Description of your changes

recovery 1

[x]  azurerm_backup_policy_vm_workload

Fixes #261
I have:

[x] Run make reviewable test to ensure this PR is ready for review.

How has this code been tested
Manually and Uptest

/test-examples="examples/recoveryservices/backuppolicyvmworkload.yaml"


Use prettier to format package-lock.json with spaces

Description

Provide description here

Type of change

[ ] Bug fix
[ ] New feature
[ ] Breaking change

Related issues

Fix #1

Migration notes

Describe migration notes if any

Extra info

Add any additional information

Awesome! Do we have this problem elsewhere? After this PR is merged, we can now approve and merge Dependabot PRs?

I hope so.


Can't change title at runtime.

Bevy version
rev = "d158e0893ea88b6acf523a4264f076d6e0b540c6"
Operating system & version
Linux Mint 20.1 Ulyssa
What you did
I tried to change the window title:
fn update_title(score: Res<Score>, mut window: ResMut<WindowDescriptor>) {
    window.title = format!("Snake: {}", score.0);
}

What you expected to happen
I expected the title to change.
What actually happened
The title stayed the same.
Additional information
I am using a WindowDescriptor to set the title at startup.
Window::set_title works, but is more verbose.

The WindowDescriptor resource is never used to update the primary window, except for when the WindowPlugin (or maybe the WinitPlugin reads it for the first time)
That is, you should use Window::set_title
This is not really a sensible default, but it's the current state of affairs.

If anyone has suggestions on ways to improve this im all ears

I have an idea... why not remove the resource once used for initialisation? #2886

I made comments on this topic earlier in the year https://github.com/bevyengine/bevy/issues/1255#issuecomment-771837798
My view for the specific issue at hand: WindowDescriptor (if that's the resource used) ideally should be an "active" resource, in the same way as ClearColor. A user simply updates a resource, and things just work. This could be as simple as a system added to WindowPlugin that monitors changes to Res<WindowDescriptor>, and automatically applies the appropriate window.set_* methods. WindowDescriptor only applies to a single window, sure, but so does ClearColor.
I made a prototype of this a while ago (just updated to work with latest main)
mod window {
    use bevy::{prelude::*, window::WindowMode};

    #[derive(Default)]
    pub struct PrevWindow(WindowDescriptor);

    #[inline]
    fn compare_f32(a: f32, b: f32) -> bool {
        (a - b).abs() < std::f32::EPSILON
    }

    pub fn update_window(
        mut prev_window: ResMut<PrevWindow>,
        curr: Res<WindowDescriptor>,
        mut windows: ResMut<Windows>,
    ) {
        if curr.is_changed() {
            let window = windows.get_primary_mut().unwrap();
            let prev = &prev_window.0;

            if compare_f32(prev.width, curr.width) || compare_f32(prev.height, curr.height) {
                window.set_resolution(curr.width, curr.height);
            }
            if prev.scale_factor_override != curr.scale_factor_override {
                window.set_scale_factor_override(curr.scale_factor_override);
            }
            if prev.title != curr.title {
                window.set_title(curr.title.clone());
            }
            if prev.vsync != curr.vsync {
                window.set_vsync(curr.vsync);
            }
            if prev.resizable != curr.resizable {
                window.set_resizable(curr.resizable);
            }
            if prev.decorations != curr.decorations {
                window.set_decorations(curr.decorations);
            }
            if prev.cursor_visible != curr.cursor_visible {
                window.set_cursor_visibility(curr.cursor_visible);
            }
            if prev.cursor_locked != curr.cursor_locked {
                window.set_cursor_lock_mode(curr.cursor_locked);
            }
            match (prev.mode, curr.mode) {
                (WindowMode::Windowed, WindowMode::Windowed)
                | (WindowMode::BorderlessFullscreen, WindowMode::BorderlessFullscreen) => {}
                (
                    WindowMode::Fullscreen { use_size: p },
                    WindowMode::Fullscreen { use_size: c },
                ) => {
                    if p != c {
                        window.set_mode(curr.mode);
                    }
                }
                _ => {
                    window.set_mode(curr.mode);
                }
            }
            // there is no set_canvas method
            // #[cfg(target_arch = "wasm32")]
            // if prev.canvas != curr.canvas {
            //     window.set_canvas(curr.canvas);
            // }

            prev_window.0 = curr.clone();
        }
    }
}

use bevy::{prelude::*, window::WindowMode};

fn main() {
    App::new()
        .insert_resource(WindowDescriptor {
            title: "Press Escape to toggle full screen vs windowed. Hit a key to change the title."
                .into(),
            mode: WindowMode::Windowed,
            ..Default::default()
        })
        .add_plugins(DefaultPlugins)
        .init_resource::<window::PrevWindow>()
        .add_system(demo)
        .add_system(window::update_window)
        .run();
}

fn demo(input: Res<Input<KeyCode>>, mut window_descriptor: ResMut<WindowDescriptor>) {
    if input.just_pressed(KeyCode::Escape) {
        window_descriptor.mode = match window_descriptor.mode {
            WindowMode::Windowed => WindowMode::BorderlessFullscreen,
            WindowMode::BorderlessFullscreen => WindowMode::Windowed,
            _ => unreachable!(),
        }
    }
    for key in input.get_just_pressed() {
        window_descriptor.title = format!("Press Escape to toggle full screen vs windowed. Hit a key to change the title. You just pressed {:?}!", key);
    }
}

One challenge I put against that is that it encourages code written with only one window in mind. That might be fine, for your specific game code, for example.
But it might not be fine for a library, as that might make it misbehave e.g. for within the editor, with multiple windows
However on the other hand, a library shouldn't be poking at your window size anyway, so it probably would be fine.

By the same token, you aren't creating multiple windows by inserting WindowDescriptor, so we don't have a multiple-windows-first API. I think we should double-down on WindowDescriptor, because it makes it less surprising. Perhaps it could be made more explicit by renaming WindowDescriptor to PrimaryWindowDescriptor.
It turns out that a side-benefit of my approach is that you can insert the WindowDescriptor after the DefaultPlugins, and it just seems to work, which makes WindowDescriptor even less surprising.
Alternatively, you could have an API that assumes multiple windows, i.e. something like
// resource
struct WindowDescriptors(Vec<WindowDescriptor>);

with the default being a vector of one. (Or each window is an entity.) This starts to get less ergonomic in the primary (usual) case of having one window.

Alternatively, you could have an API that assumes multiple windows, i.e. something like

We already have Windows for multiple windows.

I think we should double-down on WindowDescriptor, because it makes it less surprising.

Except that removing the WindowDescriptor doesn't close the window as you would expect. Winit doesn't allow programmatically closing windows at all. Only the user can close windows.

I think we should double-down on WindowDescriptor, because it makes it less surprising.

Except that removing the WindowDescriptor doesn't close the window as you would expect. Winit doesn't allow programmatically closing windows at all. Only the user can close windows.

Interesting, not something I had considered as I wouldn't have thought to close the window that way. In the case of the prototype, removing the resource would crash the application, because the system depends on it being available, which is the opposite problem that #2886 has.

Alternatively, you could have an API that assumes multiple windows, i.e. something like

We already have Windows for multiple windows.

True! WindowDescriptor is there as a "sensible default" way of initialising the window settings for the primary window - we can extend its utility by tracking the resource and updating the window settings for the same primary window. Any multiple window requirements should use the Windows resource.

Winit doesn't allow programmatically closing windows at all.

Is something wrong with winit's Drop for Window implementation? It looks like it tries to close windows programmatically to me.

Oh, didn't know about that. My bad.

Indeed, we (I've) got a pr open (#2898) which integrates that properly, now that we know about it.

Considering WindowDescriptor is only used for initialization, why not just rename it to WindowInitializationDescriptor to make it more obvious that it is only used for that?

Considering WindowDescriptor is only used for initialization, why not just rename it to WindowInitializationDescriptor to make it more obvious that it is only used for that?

Is there a reason we're married to the idea that WindowDescriptor should only be used for initialisation?

Not as far as I know, my point is that this change would be a somewhat temporary fix until a better API is found, because this isn't the first time someone got confused by the current API.

Is there a reason we're married to the idea that WindowDescriptor should only be used for initialisation?

There is one for me! It's to avoid having two ways to do the same thing

Is there a reason we're married to the idea that WindowDescriptor should only be used for initialisation?

There is one for me! It's to avoid having two ways to do the same thing

There are a couple points to this.
The first is that it represents an unintuitive way of using resources*, but we have considered a special app.insert_setup_resource() method or better docs or renaming the type.
*unintuitive because:

It fails silently if you insert it after DefaultPlugins
It fails silently when you try to change it (as per OP)
With #2886:
a.  if you had inserted it before DefaultPlugins, it crashes when you try to change it
b. if you had inserted it after DefaultPlugins, it fails silently when you try to change it
With or without #2886, it is a "dead" resource that can't be interacted with

The second is that there are already several examples of having more than one way to do the same thing.
In the best cases, there is usually an easy way in the general case, and a harder (more verbose) way that's more flexible.

Text::with_section() vs Text { .. }
Res<Input<KeyCode>> vs EventReader<KeyboardInput>
input.any_pressed([a, b, c]) vs input.pressed(a) && input.pressed(b)) && input.pressed(c))
etc.

This:
fn update_title(score: Res<Score>, mut window: ResMut<WindowDescriptor>) {
    window.title = format!("Snake: {}", score.0);
}

represents an easy way in the general case (having one window). It's easier because it's intuitive: it matches the way that you initialise the window settings, and it matches the way you initialise and make changes to other resources (and components).
WindowDescriptor tracking would likely build on top of Windows sure, but I don't see there being a problem of building one abstraction on top of another: look at Input<KeyCode>, which is a stateful abstraction over the KeyboardInput event.
Do you gain much by having that ^ over this:
fn update_title(score: Res<Score>, mut windows: ResMut<Windows>) {
    let window = windows.get_primary_mut().unwrap();
    window.set_title(format!("Snake: {}", score.0));
}

One less line perhaps, but other than that, nothing more than what's already been discussed: I think the question is whether the clarity and usability win is enough.

opened a pr to check how a startup resource would work: #2988

It turns out that a side-benefit of my approach is that you can insert the WindowDescriptor after the DefaultPlugins, and it just seems to work, which makes WindowDescriptor even less surprising.

Who knew. Moving window descriptor first is important.

Hi guys, what about using a window as an entity with components like Descriptor and other?
In that case, we could just change the descriptor of the concrete window instance.
Moreover, we can pass some special event that will indicate window update, or use some system with Changed Query (passing an event is not bad at all, but I think about efficient in that context). For the performance side of this question, we could cache window property and use them directly instead of often querying.
As for me, I wanted to implement fullscreen for my application with follow code:
pub fn fullscreen(keyboard: Res<Input<KeyCode>>, mut window: ResMut<WindowDescriptor>) {
}

Also, for some reason, I am unable to get WindowDescriptor if it wasn't set manually (LOL, where is default resource for current window?)
P.S. Too many related issues: #4386, #1255, #2988, #1144 (That one is closed but related) and so on. That is not funny. If you have chosen ECS may be the best way is to use it (It's not a critic, because seems like I don't quite understand bevy engine)?
Thanks for attention

Hi guys, what about using a window as an entity with components like Descriptor and other?

I believe that is exactly what https://github.com/bevyengine/bevy/pull/5589 does.

It looks like bors didn't close this for some reason. Fixed by https://github.com/bevyengine/bevy/pull/6336.


Configuration to mock captcha

The hack for now is:

To turn off captcha validation, edit hu.petabyte.redflags.web.svc.SecuritySvc and add this to validateCaptcha method as the first line:
if (1==1) return true;

Should be implemented as a configuration setting.

I've just built in the option to turn off captcha. If you set site.useCaptcha application property to false it will not validate the captcha and also it won't display captcha on the site.

Thank you @juzraai! I'll reopen this issue to keep in mind it's not in the documentation yet.

[ ] Include info about site.useCaptcha in the development docs

I've added it to the documentation. Currently it's here (but I may reorganize the webapp chapter later):
http://docs.redflags.eu/developer/webapp/basic/#captcha


[BSP] - Somehow signify a no-op compilation

Following up on a quick conversation on Gitter, in Metals one of the things we check when we get notified of a build/taskStart is to see whether or not it's a no-op compilation. You can see this here:
https://github.com/scalameta/metals/blob/8f1c5db0e76ddbb95db06a55afc395ca6a965d13/metals/src/main/scala/scala/meta/internal/metals/ForwardingMetalsBuildClient.scala#L117-L148
For better or worse, we just check in the message params to see if it starts with Start no-op compilation. This is Bloop specific at the moment, and you can see where this is being reported in Bloop here:
https://github.com/scalacenter/bloop/blob/4768184cc8842d5d6773646ccda93210a89f1b05/frontend/src/main/scala/bloop/reporter/BspProjectReporter.scala#L301-L331
Within Metals we do various check on this compilation to see if we need to do certain things that can in some situations offer some nice UX and speed improvements. Just to give an example we have a Tree View of all packages, and if it's a no-op compilation we know that we don't need to compute anything new for the tree view. As state, right now this is quite Bloop specific, but it'd be great to expand this somehow so that we could have a more generic approach to know if a compilation is a no-op or not from sbt. I'd love to know if this is possible and something you'd consider to forward somehow in the build/taskStart. Thanks!

In the long-term, it might be better to create a specific compilation event in BSP instead of trying to copy-paste log messages across different build tools.

In the long-term, it might be better to create a specific compilation event in BSP instead of trying to copy-paste log messages across different build tools.

Of course. I've gone ahead and created an issue in the BSP repo to discuss it to see if there is a way we can do just that, bake it into the spec.
https://github.com/build-server-protocol/build-server-protocol/issues/148


Serach, ToC & logo links fixes

Checklist

Please note that in case of below checklist not updated accordingly, the maintainers have the right to immediately close your pull request.

[x] You created a branch from dev branch.
[x] You PR is raised on dev branch and not onmaster.
[x] Blog follows Blog Guidelines.
[x] You have read the Contribution Guidelines before creating this PR.
[x] Checked for any duplicate blog entry.
[x] Checked for all grammatical errors in the blog.
[x] You have not published the blog content anywhere else on the internet on platforms like medium, dev.to etc.
[x] The content is not copy-pasted from anywhere else on the Internet.

Description of change

@pareek-narendra  Merging this directly on dev , consider all issues fixed within in this PR .
please verify this on dev , if all good , we can move to production later on


[Feature] The sharing url changes to the same as original report url

The sharing url changes to the same as original report url
PR checklist

[x] Ensure you have added or ran the appropriate tests for your PR.
[x] DCO signed

What type of PR is this?
Feature
What this PR does / why we need it:
Which issue(s) this PR fixes:
sc-30593
Special notes for your reviewer:
Does this PR introduce a user-facing change?:

Fix sc-30771


Ensure frontend uploads are owned by dpla:dpla [fixes #7769]

That would do it; thanks for the catch!
I will merge this.


Allow {module, function, args} for mixin

Contributor checklist

[ ] Bug fixes include regression tests
[X] Features include unit/acceptance tests

@jechol what's the use case here as opposed to just have a module mixin? Can you update the getting started guide with an example?

My use case is that I want to mix-in AshAdmin's admin section with name and resource group.
defmodule MyResource do
   ...
        paper_trail do
          mixin {MyPaperTrailMixin, :mixin, ["my_resource", :my_resource_group]}
        end
end

defmodule MyPaperTrailMixin do
  def mixin(name, group) do
    quote do
      admin do
        name unquote(name)
        resource_group unquote(group)
      end
    end
  end
end

@rgraff I updated guide to use {module, function, args} because it is more flexible than use.

@jechol Looks good. Thank you for your contribution. 🎉


Jorrit - action item to create language to share wth Donat and Lars how we linked existing DOIs to their associated publications in BLR / BatLit.

as discussed with @myrmoteras on 2024-08-27

See https://bhl-blr.github.io for associated text on distinguishing DOIs for physical manifestations of publications (e.g., a pdf) from the abstract notion of some scholarly work.


Negative duration for Spark job

I wonder if this is an overflow in Dr. Elephant or a bug on SHS side?

I think it's happening because the end time seems to be ZERO.<PHONE_NUMBER> is I think is the epoch time which translates to 6 May 2017, 12:06:13 GMT. Did the application start at that time?
I guess the end time is ZERO because the end time is still not reported to SHS?

Thanks @shkhrgpt, the application did indeed start about that time.

I guess the end time is ZERO because the end time is still not reported to SHS?

Do you mean that it is not finished yet, therefore there's no end time? Why would Dr. Elephant collect such applications? I thought it explicitly filters only those marked as finished by YARN.

I believe RM thinks that the application is finished, but SHS hasn't received the ApplicationEnd event for that application.  Are you using this change where fetcher checks if the eventlog has inprogress in the name or not?

Nope, this was before your PR. I'll deploy the latest version and let you know if the issue persists.

Hi I am facing the same issue when using Dr Elephant for Spark 2.0.1. Did you find the root cause?

Facing the same issue here. All times are negative.

Even I'm facing the same issue. Did we get a solution for this?

Adding a bump as I'm seeing the same issue. Jobs that have finished and show up in the SHS as complete, and which I can pull down the complete logs for, are then processed by Dr. E and fail without an application duration.


To my master branch -  [!AIO] All changes made today in one PR

Includes #1 , #2 , #3 , and #4 .

Continuous (htt)ping support (infinite pings) - see #1

In some cases, application needs to run infinitely. You can read more about Continuous Ping here .

Change - Don't sleep after the last needed ping - see #2

The change in this Push Request removes unnecessary sleep 1s , making user wait less. This is the same behavior as in standard ping.

Proxy (proxification) support - see #3

Adds support for proxies (Google Go does not support it out-of-the-box, so I utilized) rapid7/go-get-proxied

https://github.com/rapid7/go-get-proxied was therefore added to dependencies.

Add new flag - noProxy - to ignore proxies and connect directly

Implement timeout flag - see #4

Additionally, I added a much better .gitignore, updated flags in readme, and added an (IRL) example in Readme that made all these changes possible and neccessary.

lgtm


Event Request C_7321 OnBeforeFunction

We need the "OnBeforeFunction" Event in Codeunit 7321 , in the "CreatePutAwayLinesFromProd" function with the "NewWhseActivLine" record.

Variable NewWhseActivLine is local for this procedure and will be initialized by NewWhseActivLine.INIT after place for your event. Are you sure? Maybe you need event OnBeforeNewWhseActivLineInsert just before NewWhseActivLine.INSERT?

Yes you are right, this Event Request can be changed to the "OnBeforeNewWhseActivLineInsert". Thanks for the advice.


Convert Rvsdgs back into Cfgs

This PR adds a conversion from Rvsdg back to Cfg and tests it. The conversion works in a conservative way, and isn't good at re-using variables. It also doesn't implement reconstruction, so it always outputs a structured CFG for now.
It does not hook up the whole pipeline into egglog and back out. I'll be working on that next.
Merge #40 first.
Also disabled the two_fns test for now.

Thanks for the PR! This is a very clever algorithm, with a translation scheme based on IncompleteBranch and finish_block. Some high-level comments:

Is your PR tested (besides snapshot test)? It would be great to have some unit test for this conversion from RVSDG to CFG in particular, as well as "roundtrip test" to see the program produces the same output after optimization.

Yep, this pr has a roundtrip test that makes sure we get the same output after optimization. I agree some unit tests would be nice but not high priority for me right now.

I would really appreciate it if you can add some paragraph at the top of the to_cfg.rs file to explain how the algorithm works. This will help other team members to understand and contribute to this code. Right now one has to read through the entire file to understand how the algorithm works.

Good idea, I'll add it.

I saw your PR has several unrelated changes to the codebase. I think this is fine right now since the codebase is not yet stable, but in near future we should consider making the codebase more stable and have each PR more dedicated to its purpose (without unrelated changes).

Good idea, in the future I'll do unrelated changes separately. I think I struggle with that in general haha


Insufficient Information for an MVC/API App

This page doesn't really provide a clear explanation of how error handling should be implemented. It talks about "API does this, MVC does that, here's how to customize" but never really clarifies anything. If API out of the box behaves the way it should then this page would be about the defaults, customizing them and when you might. As it stands now it is completely unclear whether we need to do this for API projects or not, out of the box.
This is greatly complicated by the fact that many apps that are migrated from ASP.NET will have a mix of MVC and API controllers and the customizations/behavior discussed on this page doesn't apply to both. So it is very unclear how you can have an MVC controller return back a standard HTML error page (or the dev page) while having your APIs return the ProblemDetails information. I'm not aware of any API anywhere that would want the dev/error page returned (in any environment) for API requests. At the same time ProblemDetails is not for users so I'm not aware of any case where an MVC controller should return ProblemDetails. This page doesn't remotely touch this seemly common situation.

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 3f6504cd-a059-c5d4-73fb-61222ef1c6e0
Version Independent ID: 1b42352c-a34f-7703-aa3e-d7e3156bd0bd
Content: Handle errors in ASP.NET Core web APIs
Content Source: aspnetcore/web-api/handle-errors.md
Product: aspnet-core
Technology: aspnetcore-webapi
GitHub Login: @pranavkm
Microsoft Alias: prkrishn

I had the same reaction coming here to look up information on correct exception handling just now.
However, I dug a bit further, and if I interpret this section of the documentation correctly:
https://docs.microsoft.com/en-us/aspnet/core/fundamentals/error-handling?view=aspnetcore-3.1#exception-filters
The answer to the problem is exception filters, since you have to customize based on whether the API was requested or the main MVC app was requested. Curious as to whether one of the Microsoft documentation maintainers would agree with that interpretation, or whether the answer lies with using one of the lambdas available with exception page handling:
https://docs.microsoft.com/en-us/aspnet/core/fundamentals/error-handling?view=aspnetcore-3.1#exception-handler-lambda

Moved to #16385


FCS project cache size reduced from 50 to 10

also set FSharpChecker's keepAssemblyContents = false

It should prevent uncontrolled memory usage on many-project solutions.

I'm merging it for now. When the dynamic caches size shrinking is available, we will replace this logic with it.


time interval is not being saved after reopening the app.

need to save the time interval in config file.

resolved


flicks, countercolored

This pull request was generated by the 'mq' tool
[test]
flake rate: 0.4
logical conflict every: 5
sleep for: 300s
[pullrequest]
requests per hour: 30
deps=[c,f]

/trunk merge


AttributeError：‘DataLoader’ object has no attribute ‘size’

Hello, guys. When I run this command:
python main.py --network_type cnn --dataset cifar --controller_optim momentum --controller_lr_cosine=True --controller_lr_max 0.05 --controller_lr_min 0.0001 --entropy_coeff 0.1
I got a AttributeError：‘DataLoader’ object has no attribute ‘size’.
This is in 148 line in the utils.py. And 'Dataloader' object has no attribute 'narrow' and 'view'.  The version of pytorch in my computer is 0.4.1. Is my version wrong?
Has anyone got any ideas for this problem?

Current Implementation seemed only support nlp example task (search construction of rnn cell)
the Trainer class now only accept dataset param as torch.Tensor class rather than DataLoader
and the doc string had elaborate it.
The structure search implementation class  in shared_cnn.py not implement favor functions
consider update date of this project, should consider abandon this project.

OK! Thank you!

OK! Thank you!
I recommend you to try
https://github.com/renqianluo/NAO
it seems a mixture of current project and the official implemetation https://github.com/melodyguan/enas
except that it replaced RL learning optimize method by nlp seq2seq methods
if you prefer, You can try to fixed it into RL form.

      > OK! Thank you!

I recommend you to try
https://github.com/renqianluo/NAO
it seems a mixture of current project and the official implemetation https://github.com/melodyguan/enas
except that it replaced RL learning optimize method by nlp seq2seq methods
if you prefer, You can try to fixed it into RL form.

Thank you for your help. I will have a try.


Occsional hang when running benchmarks

Occasionally dpbench.run_benchmarks() with freeze up before completing the execution. The freeze can arbitrarily happen in different benchmarks and I have personally seen it occur in knn, kmeans, l2 and gpairs.
@oleksandr-pavlyk helped narrow down the problem to a deadlock in a DPCTLQueue_Wait. The issue needs proper investigation and a resolution.

The problem seems to be manifesting a lot since my refactoring work. I doubt though that any change I introduced is causing the problem.

@diptorupd hangs still occur?

@diptorupd, hangs do not occur now in the CI. Can this issue be closed?

I have not seen a hang for few months locally or on CI. In any case we have separate issue to track the MultiProcessing related problem (#166) can be closed.


Rotating File Option

allow option to rotate files for very large data sets

may be better left up to user :thinking:


[v4 beta-11] A disabled ion-button executes his (click) function

Bug Report
Ionic Info
Ionic:

   ionic (Ionic CLI)          : 4.1.2 (/Users/XXXX/.nvm/versions/node/v8.12.0/lib/node_modules/ionic)
   Ionic Framework            : @ionic/angular 4.0.0-beta.11
   @angular-devkit/core       : 0.8.2
   @angular-devkit/schematics : 0.8.2
   @angular/cli               : 6.2.2
   @ionic/ng-toolkit          : 1.0.8
   @ionic/schematics-angular  : 1.0.6

System:

   NodeJS : v8.12.0 (/Users/XXXX/.nvm/versions/node/v8.12.0/bin/node)
   npm    : 6.4.1
   OS     : macOS High Sierra

Describe the Bug
A function associated with a (click) on DISABLED ion-button was executed.
Steps to Reproduce
Steps to reproduce the behavior:

Add a button in the toolbar in the slot=primary
Associate any function to event (click) of this button
Disabled this button
When you click this button, the function associated to this button is executed normally, like it was activated.

Related Code
The disabled ion-button in the Toolbar:
<ion-header>
  <ion-toolbar>
    <ion-title>
      Ionic Blank
    </ion-title>
    <ion-buttons slot="primary">
      <ion-button (click)="saveData()" disabled>
        <ion-label>
          Save Outside Form
        </ion-label>
      </ion-button>
    </ion-buttons>
  </ion-toolbar>
</ion-header>

The button "SAVE OUTSIDE FORM" is disabled in the toolbar:

When click it, the function associated saveData() was executed like we can see on console:
Save was Executed with a disabled button
Expected Behavior
A disabled button can't be executed.
Additional Context
Working example here on Github: https://github.com/MrSparklle/Inc4

Thanks!

@mhartington still happens to me, just updated to<EMAIL_ADDRESS>Example:
<ion-button disabled onClick={(e: any) => console.log(e.target.disabled)} />

This actually logs true.
I would expect it to not execute the handler on click, or am I supposed to manually check that?

This appears to be a stencil/JSX issue vs an issue with the component.
In a vanilla example, the button renders correctly and pointer events are disabled.
https://codepen.io/mhartington/pen/VEZGBL?editors=1011

But in a stencil app setup, the disabled attr/prop is not getting passed to the ion-button

cc @jthoms1 and @adamdbradley


Add a way to enable or disable the app.

A little summary of the global idea of this issue

Give the possibility to choose networks where the update is not applied.
Give the possibility to totally disable the app.

I'm not sure whether this belongs here, or needs its own issue:  It'd be amazing if this app could be background-free, since it only needs to do anything whenever the device IP address changes, which is 1× per network connection change, AFAIK.
N.B.: I believe any Android (e.g., a Project Fi or Republic Wireless devices) should be able to have @ least 3 active IPv4/IPv6 addresses simultaneously: @ least 1 apiece per each active wifi's & SIM's data connections

@TPS The title and content of the issue were not very clear. I've updated them.
The current app is background free. It only react on the network_change event generated by Android.

@Willena Current means the currently unreleased master branch here, I assume?  According to Greenify, v1.0 isn't background-free.…

@TPS You're right, that's the version I was talking about.
By background-free I was thinking about services running in the background. In that case, the app has no service running in the background. But it may be possible that I do not completely close the app (aka the main activity) when you use it.
Definitely something that can be improved.
(https://stackoverflow.com/questions/3105673/how-to-kill-an-application-with-all-its-activities)

Since d8e8057 this is issue can be closed


fix: update all modified field values in root_validator when validate_assignment is on

Change Summary
Following #1971 we now run root_validator on assignment when Config.validate_assignment is set.
But we still only updated the assigned field and not all concerned fields

Related issue number
closes #2116

Checklist

[ ] Unit tests for the changes exist
[ ] Tests pass on CI and coverage remains at 100%
[ ] Documentation reflects the changes where applicable
[ ] changes/<pull request or issue id>-<github username>.md file added describing change
(see changes/README.md for details)

@samuelcolvin I took the liberty to add the bug label to all the PRs that fix regressions from pydantic 1.7+ to help you see what could be added for a possible v1.7.3
If you don't like this please let me know.
If you do, I guess a better label should be found to differentiate a regular fix and a regression on the latest release


Pretrained model

Hallo,
are you going to release a pretrained model?
Greetings

Hello, you can find the link to the pre-trained model in the updated README file.

tnx


[cicd] Simplify go CICD cache

Summary
We were double caching in some places.
I remove cache: true because this is default in v4 go action.
@loreto any reason cache was disabled for release?
How was it tested?
CICD

It was mainly to 100% guarantee that release is never accidentally "polluted" by invalid cache. That said, I think go does a good job with reproducibility, so it might be fine to turn on.


Improve documentations for 4.4.0 release

Purpose
This PR will add the following changes.

Revamp the Getting Started guide
Remove Streaming Integrator documentation
Remove Micro Integrator documentation

Quick Start Guide

If possible I would also add Podman command, since Docker might be restricted at some customers.


fix(err on no log): Returns an message indicating no log file available

:tada: This PR is included in version 2.6.6 :tada:
Your semantic-release bot :package::rocket:


Is Feign-reactive SOAP Complaint?

Are we able to make SOAP call via feign-reactive and get Mono/Flux response? No Proper documentation found for the library, please improve documentation

Any update?

Could you provide update for this doubt whether Fiegn Reactive support SOAP calls or not?

Feign client won't provide you any additional benefit for SOAP compared to direct WebClient usage.


feature: provider alternate logger

Description
I'd like to be able to override the method use to log to the console. Rather than assuming we always want to call console.log, it would be cool if that is a default but overridable with a user-provided function with some given signature.
One use-case is logging the mocked requests into the Cypress command log, so that it's clear what is going on in Polly during your tests. https://docs.cypress.io/api/commands/log.html
If you are interested in a feature like this, I'm happy to open a pull request for it.
Proposed Syntax
I would propose that, in addition to configuring logging being enabled or disabled, an alternate logger can be provided. That could look something like this:
new Polly("..", {
  logging: true,
  logger: {
    log() { ... }
  }
})

it might be interesting to allow logger itself to be a function that returns an object with the desired properties, like so:
new Polly("..", {
  logging: true,
  logger: () => ({
    log() { ... }
  })
})

Seems reasonable, I'd happily review/accept a PR for this.

A simple workaround would be exposing Logger.
Currently its hidden from cjs/esm code in @pollyjs/core/src/-private/logger.js

@vjpr are you needing this because the logger is too noisy? Would having something like logging: true | false | 'compact' | 'verbose' solve this for you?

Another workaround is do set logging: false and add your own custom logging middleware.
polly.server.any().on('response', (req) => { /* custom logging logic */})

I want to be able to see only when something is being replayed/recorded - not the full logs.


Create separate flavor for testing environment

Agree. The API at https://dgca-verifier-service.cfapps.eu10.hana.ondemand.com/signercertificateUpdate seems to hand out a lot of test certificates. Is this intentional. If this is infact the production endpoint it should probably not hand out test certificates.


Debug for attributes assignments

coverage: 51.284% (+0.1%) from 51.165%
when pulling<PHONE_NUMBER>7ef41d9c0fcce3261b87ef142debfa on debug_attributes
into 1da8ef4d3dc9a794d2b4663e41a79e520d8b1c55 on main.


Reminder - Improving project onboarding code

Need to improve the onboarding code per PR review feedback from @david-a-wheeler . The code needs optimization. This issue serves as a reminder.

Great! Just to clarify my JSON comment, since the generated files do not meet the JSON specification, it's confusing & will cause tool problems.
I think the simplest solution is to rename ".json" to ".json5", and where you insert comments, use JSON5's line comment marker "//", like this:
// This is a comment

Sometimes JSON isn't quite enough, and since all you want is JSON with comments, JSON5 should suit you perfectly & require VERY little effort of you. While JSON is used more than JSON5, JSON5 has significant support (e.g., it has built-in support in vim). More about the JSON5 format is here: https://json5.org/


Do not panic when decrypting history file

Impact
Unhandled panics can be leveraged by an attacker to cause the application to crash, thereby achieving a denial-of-service attack. This is particularly true when parsing data from an untrusted source where the attacker can influence inputs directly.
Description
This specific instance of an unhandled panic is highlighted because it may be triggered by untrusted input from the filesystem. A complete list of potential panics within the reviewed code was not completed.
The function decrypt_history_file(), as its name implies, is used to decrypt a message history file encrypted using AES-GCM, with the usual ciphertext consisting of the concatenation of a nonce, ciphertext, and authentication tag. The code parses the nonce as follows:
// Read the messages file content
let mut input_file = File::open(input_path)?;
let mut buffer = Vec::new();
input_file.read_to_end(&mut buffer)?;

// Split the nonce and ciphertext
let (nonce, ciphertext) = buffer.split_at(NONCE_SIZE);

Figure 13: xmtp_mls/src/groups/message_history.rs
The above code does not ensure that the read file is at least NONCE_SIZE bytes long and may therefore panic when calling split_at(NONCE_SIZE). Given that this file is read from the file system, an attacker may therefore be able to crash the application via filesystem manipulation.
In general, panics should be avoided in situations that do not represent a truly unrecoverable state. When leveraged, panics should include useful information to the caller or user to enable debugging or troubleshooting of the underlying problem. In the above scenario, a check to ensure that the input is at least 12 (nonce) +16 (tag) = 28 bytes could be performed prior to parsing the nonce, with a suitable Err returned instead of a panic.
The above advice is consistent with the Secure Rust Guidelines:
Explicit error handling (Result) should always be preferred instead of calling panic. The cause of the error should be available, and generic errors should be avoided.

Recommendation
Consider either adding a length check and returning a suitable Err or adding an informative message to the panic to aid in debugging.
Location
xmtp_mls/src/groups/message_history.rs

Fixed in the linked Consent Sync PR


Update P4V to latest version (2015.2-1312139)

This CL updates P4V to the latest version since the existing one (2014.3) always throws an error when exiting.

Thank you for the contribution. It was merged directly as aa73c787fb8b2cee9ab7265451752733bb0d6113 to keep commit history cleaner. Your contribution is still credited to you.


search: Don't do anything on Enter for empty search input.

This change also removes the keep_search_narrow_open option because it's no longer being used.
See conversation about this on CZO here:
https://chat.zulip.org/#narrow/stream/101-design/topic/search.20bar.20UX/near/1669261

The search still closes on Enter in Inbox, Recent conversations, and All messages. I think this is not intended?

I think that's actually going to be a much more difficult fix, that will maybe require redoing some of the logic about how the searchbar opening and closing (especially in sync with the typeahead) works. I can look into it more, but I'd de-prioritize this PR for now if we want both "enter on empty search input in Recent Messages doesn't close the search bar" and "clicking out of an empty search input when in Recent Messages does close the search bar", because there's some code that closes it right now that can't easily tell the difference.

Do you think we should deprioritize this for pre-8.0 effort, then?

That's fine by me; I think having the behavior be consistent regardless of what view you're in is important.

I filed #27605 for us to come back to later.


wordpress: update languages and plugins

Description of changes

Things done

Built on platform(s)

[ ] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
23.05 Release Notes (or backporting 22.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Thank you!

Still zero licensing information in stuff that we redistribute.
https://github.com/NixOS/nixpkgs/issues/202191