cache write race condition across processes

Do you want to request a feature or report a bug?
bug
What is the current behavior?
When running tests in parallel with the new atomic cache writing, we're getting rename errors as multiple processes try to write to the same files.  Even with --no-cache option set it's still hitting rename errors because it's still trying to write to the files.
What is the expected behavior?

I think that --no-cache should not write cache files
Caching across multiple processes should not collide, or should be able to restart the test.

Please provide your exact Jest configuration and mention your Jest, node, yarn/npm version and operating system.
{
	"clearMocks": true,
	"collectCoverageFrom": [
		"packages/**/src/**/*.{ts,tsx}",
		"!packages/sf-lint/**",
		"!**/*.d.ts"
	],
	"coverageReporters": [
		"text-summary"
	],
	"moduleFileExtensions": [
		"ts",
		"tsx",
		"js",
		"json"
	],
	"setupTestFrameworkScriptFile": "<rootDir>/jestEnvironment.js",
	"transform": {
		"\\.(ts|tsx)$": "<rootDir>/scripts/preprocessTypescript.js",
		"\\.(less|css|svg|gif|png|jpg|jpeg)$": "<rootDir>/scripts/preprocessText.js"
	},
	"testRegex": "(Spec|.spec).tsx?$"
}

jest 21.0.1
node 6.9.2
yarn 0.27.x/1.0.0
OS Windows

Isn't this related? https://github.com/facebook/jest/pull/4432

I don't believe so.  I believe the case we see in our repo is the exact same file getting mocked for 2 different processes (while running in parallel) which causes the cache write operation to fail because one process has the file locked.  That ticket looks like is more about different files with the same contents.  We don't have any of those cases in the repositories we host that we ran into this issue.

We basically run into the same issue with our tests. One easy way to reproduce was to remove jest cacheDirectory to force cache generation on the next run.

    jest: failed to cache transform results in:
C:/myniceproject/src/jest-cache/jest-transform-cache-b2e8f1f700b9bd266a0d27bb01b47a2b-34a7e3d71d38ff01f65fdb5abdf5126b/3f/settingsProvider_3f1439e55275a95ecfdb7dcb432f7958
   Failure message: EPERM: operation not permitted, rename
'C:\myniceproject\src\jest-cache\jest-transform-cache-b2e8f1f700b9bd266a0d27bb01b47a2b-34a7e3d71d38ff01f65fdb5abdf5126b\3f\settingsProvider_3f1439e55275a95ecfdb7dcb432f7958.1630729137'
->
'C:\myniceproject\src\jest-cache\jest-transform-cache-b2e8f1f700b9bd266a0d27bb01b47a2b-34a7e3d71d38ff01f65fdb5abdf5126b\3f\settingsProvider_3f1439e55275a95ecfdb7dcb432f7958'`

Having the same issue and can't find a way around it. Jest is basically unusable for us like this.

We are trying to update to 21.2.0 from 20.0.4 and now we have the following error on our build servers:
Test suite failed to run
[13:46:50]
[13:46:50]    jest: failed to cache transform results in: C:/TeamCity/buildAgent/temp/buildTmp/jest/jest-transform-cache-c60bb8ad55f1dbc29115038800657f2f-4895fc34da3cd9ad1e120af622bca745/3b/fe-selectors_3b56db772e798e2e4d0c9fc7c9e4a770
[13:46:50]    Failure message: EPERM: operation not permitted, rename '...\jest\jest-transform-cache-c60bb8ad55f1dbc29115038800657f2f-4895fc34da3cd9ad1e120af622bca745\3b\fe-selectors_3b56db772e798e2e4d0c9fc7c9e4a770.1701848979' -> '...\jest\jest-transform-cache-c60bb8ad55f1dbc29115038800657f2f-4895fc34da3cd9ad1e120af622bca745\3b\fe-selectors_3b56db772e798e2e4d0c9fc7c9e4a770'
[13:46:50]
[13:46:50]      at Object.fs.renameSync (fs.js:772:18)
[13:46:50]      at Function.writeFileSync [as sync] (node_modules/write-file-atomic/index.js:192:8)

I'm now having the same issue tests are broken randomly.

If I run the tests with the --runInBand flag then as expected everything is OK.

Tried setting --maxWorkers=2 and got the following. Sounds like it might be related to this issue:
Error: AggregatedResult must be present after test run is complete
    at /home/ubuntu/action/node_modules/jest-cli/build/cli/index.js:85:15
    at Generator.next (<anonymous>)
    at step (/home/ubuntu/action/node_modules/jest-cli/build/cli/index.js:45:2466)
    at /home/ubuntu/action/node_modules/jest-cli/build/cli/index.js:45:2626
    at <anonymous>
    at process._tickCallback (internal/process/next_tick.js:188:7)

I can see the same issue fairly consistently:
  ● Test suite failed to run

    jest: failed to cache transform results in: .../jest-transform-cache-...
    Failure message: EPERM: operation not permitted, rename '...' -> '...'
        at Error (native)

      at Object.fs.renameSync (fs.js:810:18)
      at Function.writeFileSync [as sync] (node_modules/write-file-atomic/index.js:192:8)

jest 21.2.1
node 6.11.1
OS Windows
--no-cache does not help and jest-transform-cache is still being written. The only thing that helps is --runInBand, which is hardly acceptable for large projects.
Anything we can do to help diagnose the issue? Should I create a repro case?
Is this error critical? Can it be treated as a warning rather than taking down the whole test suite? Is there a way to back off and retry?

Having a small repro would be great

Here's the repro: https://github.com/asapach/jest-cache-issue/
It effectively runs lodash-es through babel-jest to populate the transform cache.
This fails for me 80% of the time on two different machines (Win8.1 and Win10).
If you remove --no-cache it fails 100% of the time.

Is this just happening on Windows? I don't have access to windows machines beyond virtual machines, so not the easiest to debug for me...
@jeanlauliac you added write-file-atomic in #4088, would you be able to help out?

This problem is very similar to https://github.com/npm/write-file-atomic/issues/10.

Just ran a procmon trace, here's an example of the issue:

Time of Day
Process Name
PID
Operation
Path
Result
Detail

16:54:43.2304011
node.exe
7624
SetRenameInformationFile
...\constant_ee286bbcf367680ce61a90e506522f92.82986661
SUCCESS
ReplaceIfExists: True, FileName: ...\constant_ee286bbcf367680ce61a90e506522f92

16:54:43.2305499
node.exe
8208
SetRenameInformationFile
...\constant_ee286bbcf367680ce61a90e506522f92.103872574
ACCESS DENIED
ReplaceIfExists: True, FileName: ...\constant_ee286bbcf367680ce61a90e506522f92

As you can see two processes are trying rename the same file within 1ms of each other and the second one fails.
I think npm/write-file-atomic#22 addresses the async version of writeFile(), but writeFileSync() is still affected.

Would it be possible to create a repro showing that just using write-file-atomic in worker-farm against the same file fails somehow? Would be great to open an issue against that project, as I think that's where the fix should be.
Or if you could write a test within jest that shows the same error (we have appveyor CI) that could be a start as well?
I'm not even sure what behavior we want in case of this error. Retry the write? Rerun the test? The whole test file?

OK, I'll try to create another repro. Not sure it's possible to create a jest test, because it would require spawning multiple processes, disabling/cleaning the cache and keep running until it fails.

I'm not even sure what behavior we want in case of this error.

Well, firstly the issue should not even happen when --no-cache is on, since the cache should not be populated.
Secondly, I'm not sure it's possible to retry the sync operation properly - is it possible to use writeFile() instead of writeFileSync()? That way write-file-atomic should retry automatically (I'll create a test to confirm).

Well, firstly the issue should not even happen when --no-cache is on, since the cache should not be populated.

That's a good point, and should be fixed separately. That way --no-cache can at least be a workaround.

Secondly, I'm not sure it's possible to retry the sync operation properly - is it possible to use writeFile() instead of writeFileSync()?

@cpojer thoughts on making it not be sync? Not sure how that scales. Or if you have another idea on how to fix this

--no-cache is more like --reset-cache actually. It means it won't use the existing cache, but it will still write cache. I'd like to retain that.
These operations have to be sync, because they happen during require calls in user code, so we can't change that.

Here's the other repro with worker-farm and write-file-atomic: https://github.com/asapach/write-atomic-issue
Findings so far: the sync version fails as expected, but surprisingly the async version fails as well. This means that they probably implement a retry queue only when it runs in the same process, which doesn't help in our case.

I'd like to retain that.

New flag? It's a highly misleading name. And on e.g. CI you rarely want the cache anyways, so it's just wasted resources.

Here's the other repro with worker-farm and write-file-atomic

Awesome! Could you open up an issue against write-file-atomic? It feels like a fix should go there, and if not (they don't want to support multiple processes writing at once) we can revisit on our side. WDYT?

A patch I tried locally that seemed to work is ignoring the error if it comes from trying to rename to a file with the same content. Since it just means another process 'won' the race, we can ignore it and move on.
const cacheWriteErrorSafeToIgnore = (
  e: Error,
  cachePath: Path,
  fileData: string,
) => {
  if (
    e.message &&
    e.message.indexOf('EPERM: operation not permitted, rename') > -1
  ) {
    try {
      const currentContent = fs.readFileSync(cachePath, 'utf8');
      return fileData === currentContent;
    } catch (e) {
    }
  }
  return false;
};

@SimenB, sure, I'll file an issue.
@cpojer, can this error be swallowed/ignored and treated as a warning? It implies that the file has already been written and no data should be lost.

Upstream issue: npm/write-file-atomic#28

I think this means "rename" is not an atomic operation on Windows, so it breaks the assumption made by write-file-atomic. Unless there's a flag that could be enabled at the Windows API level, this could mean it's impossible to have atomic writes/renames on Windows altogether.
@jwbay your solution looks reasonable to me! 👍   Instead of using indexOf however, I'd use e.code === 'EPERM' (more robust, doesn't depend on specific message). I don't think we should read the file again to check the value, because this could introduce additional concurrency issues (ex. if the file is being written by yet another process at the same time). Would you mind sending a PR, please?

I was about to start work on a PR for write-file-atomic along the lines of "if we're asked to write a file sync but it's already in the queue to be written async, bail out" (maybe with an option to switch the behaviour on). But if we're happy to handle this at the Jest level, I won't hurry. cc @jeanlauliac

I was about to start work on a PR for write-file-atomic along the lines of "if we're asked to write a file sync but it's already in the queue to be written async, bail out" (maybe with an option to switch the behaviour on).

I think adding this logic wouldn't fix the issue, because it happens when different processes try to write to (rename to) the same file.
To fix concurrency issues once and for all, we may have to reconsider how we do caching, for example have a single process that access the cache, with which we communicate over some kind of IPC. Existing key/value store systems may be handy, such as memcached.

I think adding this logic (local queue) wouldn't fix the issue, because it happens mostly when different processes try to write to (rename to) the same file.

Ah, I perhaps misunderstood the issue then. The way I read it, the library already has a queuing mechanism that works nicely for the async requests, but if you mix in sync requests as well you can get collisions.

@mekwall, I think they are using rename() in the async version of writeFile(), and it still fails in my test: https://github.com/asapach/write-atomic-issue. Could you please try running my repro? I think your change might minimize likelihood of this problem happening, but does not eliminate it completely.

@mekwall, yep, still failing with your changes (although async-ly). And hangs the process because of all the setTimeout()-s.

Or rather technically it doesn't fail (because the sync flow is not interrupted), but the console is still littered with EPERM errors.

@asapach I found the issue you're having. It's in the graceful-fs polyfill. I've posted a fix in this PR: https://github.com/isaacs/node-graceful-fs/pull/119

@mekwall, yes this does seem to address the issue - no more errors in both sync and async versions.
The problem now is that temp files are not removed, because fs.unlinkSync(tmpfile) is never called: https://github.com/npm/write-file-atomic/pull/29/files#diff-168726dbe96b3ce427e7fedce31bb0bcR198

@asapach I added unlink to graceful-fs rename, but I'm not sure if that's the right way to go. Afaik fs.rename uses the MoveFile function and that should not copy the source to the destination. The source should just change name and the source and destination should never exist at the same time.

@mekwall, that does help a bit, but in some cases if the worker is terminated early (because all the work is done), some files are not cleaned up, since it doesn't wait for the cleanup. The async version seems to work fine.

@asapach It's not working as expected at all. I need to dive into the innards of node to figure out how it's actually  working and what the intended behavior should be. I believe the whole point with graceful-fs is to have it work the same on every platform, so I'll dig deeper into that. At least we've found the culprit :)

@asapach I realized that my PR for write-file-atomic wouldn't work, so I took another approach by adding fs.renameSync in graceful-fs with the same workarounds as fs.rename but blocking. This makes your test work just as expected!

@mekwall, Thanks, I've verified your changes on both of my repro cases and none of them fail.
I think on the downside I see increased CPU and disk usage for sync, but it's probably expected.

Thanks a lot folks for picking this up and helping to get it fixed. Much appreciated! ❤ Hopefully the fix in graceful-fs is the correct one, and it gets released.

 We're pained by this at work so I got some time to investigate this by my team. The changes will affect a lot of packages so it will most likely take time for them to accept it :/

Any idea when this workaround will make it to a release?

@cpojer could you provide some more info why it's closed? is there a fix provided? We still have this issue

Apologies, seems like the fix has not landed in graceful-fs yet :(

Can multiple people confirm that using https://github.com/isaacs/node-graceful-fs/pull/119 fixes their issues?
You can use the fork by using yarn resolutions, see https://yarnpkg.com/en/docs/selective-version-resolutions, which should allow you to deploy the fix to CI etc.
e.g.
{
  "resolutions": {
    "graceful-fs": "mekwall/node-graceful-fs#a10aa576f771d7cf3dfaee523f2e02d6eb11a89f"
  }
}

@SimenB It solves the issue for me, at least 😄

+1 For me as well.

@SimenB Also fixed my issue and I'm now able to use yarn 22 on windows. (We were stuck on 20 before this).

Yarn 1.0.0 should be enough, worth a try upgrading, though

This is a major issue for me and nothing has happened with graceful-fs since November 2016 of what I can see. So I'm getting quite pessimistic that the fix @mekwall provided won't be merged any time soon. Is there any temporarily solution we can use other than the -i flag and the resolution workaround?

Does --runInBand not work for you @frenic?

That's the same as -i and yes, it works. But unfortunately it's not sustainable in the long run for larger projects.

I guess we could fork and publish our own, but it doesn't seem like the fix works for everybody

I'm up with the same situation, but in my case, --runInBand doesn't work.

I've checked the graceful-fs override with the latest version of Jest and unfortunately it no longer seems to work as reliably since I last tested it. There's still non-zero chance that it runs into a race condition on large test suites.

After scrolling through this thread, I found a resolution using yarn. Is there a resolution using npm instead?

We have had pretty good luck so far just referencing the patched version of graceful-fs to our package.json
"graceful-fs": "https://github.com/mekwall/node-graceful-fs.git#patch-1",

Hi,
For some reason we only get this error when running from Jenkins, not when run locally (even on same machine/folder etc.)
@jsheetzati 's solution is working for us too (using npm), but it is a patch after all. Is there an ETA for resolving this permanently?
Thanks,
Mor

We're also having this issue when running jest from Jenkins. --runInBand option helps to avoid failure during single job execution but jest still fails when running several builds in parallel.
As a workaround we use lockable resources plugin to make sure that only one jest process is executed at the same time keeping the --runInBand option.
Hope this comment will be useful for someone.

@nyrkovalex What we do to avoid the issue you're describing is use Jest's cache directory option to make sure the cache is not shared.
We do so by publishing a Jest preset that sets cacheDirectory: '<rootDir>/.jest-cache' and making  sure that all packages use it. if doing so make sure to add .jest-cache to .gitignore

@anescobar1991 That option is definitely a better solution, we'll consider using it.
Thanks for a tip!

Hi,
we use gradle to run npm (don't ask why :) ) and the combination of that with Jenkins is a killer.
We tried:

setting the cache to be on the local directory instead of global cache
using --runInBand
only a single job running on the agent- no parallel jobs
running gradle test --max-workers 1 (and not using --parallel)

All fail with the same error.
The only solution that works for us is the one by @jsheetzati - I wish this would get formally fixed.

We could probably fork and publish with that fix

that would be awesome...

I have this problem a lot and the patch for graceful fs worked for me. So i  would appreciate this fix.

As a workaround to fiddling with graceful-fs, couldn't you simply give each worker process / thread it's own cache directory to avoid the race condition?
It's probably slow, but we have to use --runInBand on our CI server and that is way worse.
If someone can point me at the right files to look at, I might even try to write a patch. I have a really hard time navigating the source of jest.

I'm not sure what it is but it has been a few weeks possibly month and I haven't observed the failure anymore. We have been using jest 22.4.2 for a while and upgraded to 22.4.4 recently. We've also updated various other packages.

Also running into this issue, any insights into a better/permanent fix?

This started again for us in the last couple of months - windows - very intermittant.
write-file-atomic no longer uses graceful-fs - maybe that has something to do with it?

After moving to high cpu build machines we see this now daily - which is very annoying.
We've patched the write-file-atomic package with logs and work-arounds. The main problem is that sometimes after a EPERM the original file does not exist. Add a 100ms wait and then seeing if it exists, it seems to find it in most cases - but I got one error still (without enough logs.. so re-running), so I suspect its also possible for 2 renames to collide and both to error and neither to succeed.
We would like to not maintain a over-ridden version of write-file-atomic but also write-file-atomic seems like a non-ideal place to put it - for jest we only care that the new file is written - for write-file-atomic that is not necessarily the users case.
Would you accept a patch to fix this in jest? its going to be pretty ugly though :(
Probably the non-ugly way is to stop using write-file-atomic and instead use a multi-process mutex mechanism that stops the file being transpiled x times in the first place. Also make all this code async..

I think I have a better handle on whats going wrong - we don't see two renames colliding and nothing happening in one. We see something like this.
process 1 - rename file
process 2 - rename file
process 2 - error
process 2 - patch logging - check if file exists - it does exist
process 1 - finished ok
process 3 - rename file
process 2 - check if file exists - it does not exist because process 3 is overwriting it?!
This happens on fast build machines with 15 processes running - when I log for rename collisions, we get ~55k collisions, so its not surprising that 1 in 100k hits an error like the above.
Its made worse by us evergreening dependencies on a daily basis as that clears the cache.
After some thought I think the best option for us is to ignore errors, rather than try again.
Can anyone from the core team given this analysis tell me what patch you would accept?

We have been running with the fix I made a PR for - no response from the jest team.
We also get this error: failed to read cache file
also reported here: https://github.com/facebook/jest/issues/3630#issuecomment-632046762
We have write-file-atomic, which isn't actually atomic and then we have a read process that on any error tries to delete the file... so write-file-atomic might be in the process of writing the file, reading may fail, write file atomic has finished, the file is deleted and meanwhile in another thread its passed the file exists condition but meanwhile has been deleted, so it fails and then fails the test.
We run jest for ~5 mins, 180 times a day on machines with 16 cpu's and this happens once a week, but its still pretty annoying as every unit test failure requires manual intervention. For people who run smaller projects this will only come up very very occasionally, but it doesn't mean it doesn't happen.
@SimenB sorry to tag you, but I haven't otherwise managed to get any engagement on what we can get merged to fix this.
I can make jest just print a warning but not break? I can add a option to ignore cache file system errors? a env variable? ignore errors but only in windows?

@lukeapage have you published an npm package with the fix (eg namespaced package)? I'd like to try it out if possible - provide feedback if that's useful.
This gremlin bites us sometimes - but when it starts, the build has to be mashed a good few times to get it working again. We have 200+specs, 2000+ tests in a particular project, and quite likely that specs will require shared resources, so we tend to hit this more often than "once in a while".

Actually we patched write file atomic for the write issue as I really didn’t want to maintain a fork of jest transform. If you want you can point at the git commits of the pull requests above, but they are off master so I have no idea if they will work with a specific jest version.
If I don’t get any response here I will give it a go to maintain a fork just of jest transform against each version of jest I use and then use yarn to rewire to my forked version.

good catch - I spent very little time chasing this down, but what you've put in there is about what I've been thinking should have been the behavior: caching should be to speed things up - a cache miss or failure should be non-fatal - I'd probably want to do the same patch on writeCacheFile.
I don't think it's going to be too hard to write a pre-processor to alter this file, now that I know where it is. Thanks again for the code link - this issue has been outstanding for so long and caused so much wasted time that I think it's worth spending the time on a manual patch, since it looks like it's never going to get fixed ):

fwiw, for anyone reading this, I've made a little cli tool to patch ScriptTransformer.js in the @jest/transform folder, operating on locally-installed modules; so far, it's running as part of my CI pipeline after 5 successive failures the other day for cache read / write errors. A build which fails due to this error costs my QA 10 minutes per shot, so successive fails like this are an hour wasted in the day.
Check it out here: https://www.npmjs.com/package/patch-jest-cache
I haven't seen the (default) warnings that it should emit on an error, so, so far, I'm "lucky" enough not to be hitting the issue after my 5-in-a-row, but the good news is that my tests run and pass, so at least I know that the "happy path" works. The code is fairly well tested too.
If you'd like to use it:
npx patch-jest-cache

if you (like our one project) have a base dir with node_modules and a src dir, this tool will run a lot quicker if you tell it where to run (as it has to find ScriptTransformer.js - use npx patch-jest-cache --in src
it's safe to run multiple times in succession against the same installed module and can be undone by simply issuing npm ci / npm install (whichever you prefer)
patch-jest-cache will break if it finds multiple ScriptTransformer.js files (eg monorepo) - that's me being overly cautious, in case there really are repeated files at some point in the future.
patch-jest-cache can also be used to properly disable caching, as I've found that the command-line argument --no-cache still makes jest waste IO time whilst writing out cache files that it won't use.
As with most open-source, free code, YMMV, I accept no liability for any damage, if it breaks, you can keep all the pieces. The patching process is inspired by @lukeapage (thanks!).
If you're wondering "why bother?" - that's a good question. As far as I can tell, this only affects windows users (though there are reasons caching could fail on !windows) - but that's my test / build target. Since this has been an open issue for nearly 4 years, I don't have a lot of confidence that it will get fixed soon - though perhaps the mere presence of a horrid hack like my patcher may change that.

activity

We're still using patch-jest-cache on our CI builds. Just the other day I had to help some team members use it on their own machines because they were experiencing repeated failures. It is a hack, but I highly recommend it to anyone in this discussion as it looks like this is never going to be resolved.
The solution should be simple too: have a look inside patch-jest-cache to see that all it does (by default) is make the caching opportunistic: we attempt to write to the cache, but if we can't, no biggie: a minor slowdown matters a whole lot less than entirely failed test runs.

Same here - we use it for all installs - a hundred developers and hundreds of ci builds a day.

Same here - we use it for all installs - a hundred developers and hundreds of ci builds a day.

glad to be of help - since npx apparently does really good caching, I see a download count  of ~200/day and think that most people don't care :D

We use a npm proxy so you don’t even see our usage…

well, it's good to know that it's helping someone - I don't need massive download numbers, but knowing that it relieves an issue for someone else is plenty good enough (:

Cheers for the tool @fluffynuts! Might it be worth putting a PR into jest with the updated ScriptTransformer and hope someone reviews/merges it?

@samboylett two prs are open but I’ve not got the maintainers to engage with them. The prs are linked further up in the thread.

this is the crux of it - and why the tool exists - the maintainers don't care because it doesn't affect them, even though it's bad design (cache is to speed up execution and should not be a lynch-pin). Perhaps someone will listen if enough noise is made here, but I highly doubt it. I've seen a lot of the attitude that failures on "that os" don't matter (because these failures are windows-specific) or "just use WSL", and that's what you're going to find more of. Sorry to come down with the Hammer Of Cynicism, but this issue has been open for nearly 5 years and the fix is trivial - if the maintainers cared, it would be implemented already.

I apologise for (a) my hacky tool and (b) my attitude - 5 years is a long time to wait for a trivial fix

@chekrd have you tried using my hack-around? npx -y patch-jest-cache run in the folder containing node_modules, or npx -y patch-jest-cache --in C:\folder\containing\package.json
I'm afraid that's the best I can offer; it looks like this isn't going to get attention because it only affects windoze clients (afaik) and no-one cares (:

I'd like to see the errors. Those other scripts under there, funnily enough, don't always have the same hash as the one in the base. I'd have to check if the patch can be applied throughout - it might be fine since it attempts to be smart, "looking for" the relevant functions and replacing them with more tolerant versions.

hm, that's interesting, because the function should be made tolerant by default; disabling write cache does what it says on the tin - disables any writing to the cache whatsoever. I'll try have a look at this Sometime Real Soon Now (:

@chekrd, I have a beta version if you'd like to try
npx -y patch-jest-cache@beta

there was significant re-work to go from a singular process to batching all of them, so, whilst all the tests pass, and it's working in my work repo, I'd like confirmation from others before simply unleashing this as it seems as if a few hundred people are using this regularly. I don't want to cause anyone undue hassles 😅

so I can try to repro, please provide the exact version of jest you're using?

@fluffynuts strange the ScriptTransformer contains a cacheWriteErrorSafeToIgnore function that should fix this issue:
const writeCacheFile = (cachePath, fileData) => {
  try {
    (0, _writeFileAtomic().sync)(cachePath, fileData, {
      encoding: 'utf8',
      fsync: false
    });
  } catch (e) {
    if (cacheWriteErrorSafeToIgnore(e, cachePath)) {
      return;
    }

    e.message =
      'jest: failed to cache transform results in: ' +
      cachePath +
      '\nFailure message: ' +
      e.message;
    removeFile(cachePath);
    throw e;
  }
};

const cacheWriteErrorSafeToIgnore = (e, cachePath) =>
  process.platform === 'win32' &&
  e.code === 'EPERM' &&
  fs().existsSync(cachePath);

Okay I made some progress: the problem seems to be the fs().existsSync(cachePath) check.
In some cases, under windows if you have no access to the file, also fs().existsSync(cachePath) will return false!

The problem is half fixed in master - it is missing https://github.com/facebook/jest/pull/11104
The half fix that is merged is
https://github.com/facebook/jest/pull/11423

The problem is half fixed in master - it is missing https://github.com/facebook/jest/pull/11104
The half fix that is merged is
https://github.com/facebook/jest/pull/11423

Okay somehow I missed your PR. But exactly the same change I made in my PR 😊 So I can close my PR.
In https://github.com/nodejs/node/issues/17921#issuecomment-362300433 it will be mentioned that fs.exists will return false on EPERM error so it is clear that the current code can not work.
But why has you PR not been merged?

We are using forked CRA v5.0.1 that uses Jest v27.4.3.
Is the issue fixed in latest jest, and we should try to upgrade it?
Reading this long discussion, It seems, it is easier to try using WSL.
We are using

Windows 10
Jenkins
Node version - 16.15.1
pnpm version - 7.18.1
Jest version - 27.4.3

Issue happen pretty often.

I'm getting this issue too. Only a few hundred tests in my codebase.

@AngusMacrae have you tried my hack-around? npx -y patch-jest-cache

We started using Linux agent for Jenkins. It fixed the issue.

We started using Linux agent for Jenkins. It fixed the issue.

well, it works around the issue because linux can do COW for files in use, but yes - this is why the issue has remained unfixed in Jest: I think most people are using linux or osx so they just don't care :|

We started using Linux agent for Jenkins. It fixed the issue.

well, it works around the issue because linux can do COW for files in use, but yes - this is why the issue has remained unfixed in Jest: I think most people are using linux or osx so they just don't care :|

Yes, it is a pity that nobody cares about this issue.

@fluffynuts seems jest v30 will break jest-patch-cache
https://www.npmjs.com/package/@jest/transform/v/30.0.0-alpha.1?activeTab=code
Because now all the files are bundled into one index file

@fluffynuts seems jest v30 will break jest-patch-cache
https://www.npmjs.com/package/@jest/transform/v/30.0.0-alpha.1?activeTab=code
Because now all the files are bundled into one index file

hooray! :D PRs welcome; I don't really have the time to look at this rn and we haven't upgraded to that yet, so I guess I can put it off for a bit :D

My focus is going to be on getting this PR merged: https://github.com/jestjs/jest/pull/11104
which I believe will solve the issue for good and retire your tool.
as per previous comments the other change which was merged was: https://github.com/jestjs/jest/pull/11423

My focus is going to be on getting this PR merged: https://github.com/jestjs/jest/pull/11104
which I believe will solve the issue for good and retire your tool.
as per previous comments the other change which was merged was: https://github.com/jestjs/jest/pull/11423

Good luck 🙂 I'd like nothing better than for my hack to be retired.

Nothing is more permanent than a temporary solution.

Upgrading write-file-atomic to 6.0.0 seems to solve issue for me, had to use npm overrides (yarn resolutions) to force the installed package version though.


Legend GetBitmap throws System.ArgumentException: 'Parameter is not valid.'

ScottPlot 4.1.09-beta
I'm having problem displaying and saving Legend.
Legend doesn't shows on the Plot.
When calling  Plot3.Plot.Legend().GetBitmap(false) an exception System.ArgumentException: 'Parameter is not valid.' is thrown.
Code for using and updating Plot in an WPF .net 5 aplication.
public WpfPlot Plot3
{
    get { return _plot3; }
    set { SetProperty(ref _plot3, value); }
}

<ContentControl Grid.Column="2" MinWidth="200" MinHeight="200" Content="{Binding Plot3}"></ContentControl>

var legendBitmap = Plot3.Plot.Legend().GetBitmap(false);

Hi @mzemljak, thanks for reporting this!
It looks like the problem arises when using the old API to request the legend before the plot has been rendered. I'll update the code so it performs the expected behavior. For now, here's a quick fix using the latest beta / pre-release version
var plt = new ScottPlot.Plot();
plt.AddSignal(ScottPlot.DataGen.Sin(51), label: "test");
plt.Legend().OutlineColor = System.Drawing.Color.Transparent;
System.Drawing.Bitmap bmp = plt.RenderLegend();
bmp.Save("legendTest.bmp");

PS: Note the transparent outline is required to ensure the 1px border doesn't show-up in the saved image. I'll fix this when I work on the rest of this issue.

I added an improved exception error message when trying to get the bitmap before it's rendered, and I fixed the issue that required the transparent outline hack.
I'll release this on NuGet tonight. Thanks for the initial report @mzemljak!
System.Drawing.Bitmap bmp = plt.RenderLegend();


Enable firmware rollback from HCL report

Tested, fw dumped in hcl report is extracted and detected. Next flashrom used it to rollback to older firmware version. Closing this one.


Updating Graph ResourceId in web.config

The ResourceId was set to graph.windows.net while correct graph resource is graph.microsoft.com as defined in https://graph.microsoft.io/en-us/docs/authorization/app_authorization. With graph.windows.net calls to graph api return 401 unauthorized.

They are both valid. It only depends on which one you configure your application in AAD for. Not everybody has Office 365 and therefore not everybody will have graph.microsoft.com so I'd rather just leave it with the option that is more likely going to work for most people

A few asks:
1-Let's not publish aad or bot secrets on GitHub. Please remove those
2-Let's not change the aad grah resource id into Microsoft graph. That demo is supposed to work even for folks who don't use Office 365.
Thanks


Prepare to release AppContainers 1.1.0-beta.3

Contributing to the Azure SDK
Please see our CONTRIBUTING.md if you are not familiar with contributing to this repository or have questions.
For specific information about pull request etiquette and best practices, see this section.

API change check
API changes are not detected in this pull request.


Add FAQ questions related to LogStash and Fluent

Signed-off-by: Naarcha-AWS<EMAIL_ADDRESS>Description
Fixes part of issue from the Documentation Project, https://github.com/opensearch-project/documentation-website/issues/467
Issues Resolved

https://github.com/opensearch-project/documentation-website/issues/467

Check List

[x] Commits are signed per the DCO using --signoff

By submitting this pull request, I confirm that my contribution is made under the terms of the BSD-3-Clause License.

@stockholmux: Do you know if there's any config adjustments I need to make to add these new questions to the FAQ? It looks fairly automated but want to make sure before we merge.

@Naarcha-AWS No, it's all automatic.


As a developer using the reference implementation, I want to be able to run the reference implementation on my local machine.

We probably want to add/improve documentation on this. It is obviously possible to run locally, but we should probably put it either in README or documentation site so it is clear what is all needed.


Notebooks to be excecuted for HTML rendering

We use auto that will leave the option of including outputs for notebooks where we expect the cells to run for a long time.
Note: the rendering should not be the most thorough test, we still need to add e.g. version dependent testing, etc, but that's best done in separate jobs.

This is ready for review now. Additional changes:

Fixed headings to be consecutive.
Added auto-generated TOC instead of the hard-wired ones.
pulled out of circleCI for testing, we only use it atm to provide the rendered link above.

I would suggest to review/merge this PR as is, and I'll come back with the outstanding TODO items in follow-ups.
TODO:

add cron
add multi-version testing, including pyvo-dev
turn sphinx warnings about  code exceptions into proper failures

What we don't do, is to test for the expected output, we only check that the cells run. But as the notebooks doesn't have their outputs saved I don't see how we could test for that type of content.


Add Dockerfile for Jenkins slave

I pushed the image to Docker hub. I called it dalg24/dumb-slave.

Current coverage is 89.60%

Merging #125 into master will not affect coverage as of 6687822

@@            master   #125   diff @@
=====================================
  Files           66     66
  Stmts         4145   4145
  Branches         0      0
  Methods        276    276
=====================================
  Hit           3714   3714
  Partial          0      0
  Missed         431    431

Review entire Coverage Diff as of 6687822

Powered by Codecov. Updated on successful CI builds.


Update cats-effect, cats-effect-laws, ... to 3.3.2

Updates

org.typelevel:cats-effect
org.typelevel:cats-effect-laws
org.typelevel:cats-effect-std
org.typelevel:cats-effect-testkit

from 3.3.1 to 3.3.2.
GitHub Release Notes - Version Diff
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

Files still referring to the old version number
The following files still refer to the old version number (3.3.1).
You might want to review and update them manually.
core/shared/src/main/scala/org/http4s/ResponseCookie.scala

Ignore future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "org.typelevel" } ]

labels: library-update, early-semver-patch, semver-spec-patch, old-version-remains, commit-count:1

Superseded by #5801

Superseded by #5802.

Superseded by #5802.


Use name Robert Koch Insitute consistently on FAQ pages (EN)

This PR corrects some incorrect naming of RKI in the English language FAQ entries on https://www.coronawarn.app/en/faq/.
The correct English language name is Robert Koch Institute according to the Imprint of RKI website.
The correct German language name is Robert Koch-Institute according to the Impressum of RKI website. There were some incorrect usage Robert-Koch-Institute (with a hyphen between Robert and Koch) on the English language FAQ page.
I changed the incorrect German names to the correct English name "Robert Koch Institute" in faq.json for publishing to https://www.coronawarn.app/de/faq/.
(I checked also the German FAQ page https://www.coronawarn.app/de/faq/ and this was already correct.)

I am closing this PR since it conflicts with the merged PR https://github.com/corona-warn-app/cwa-website/pull/934 for the Czech Republic. Unfortunately git can't handle it well because the whole interoperability table is on one .json source line.
If you would like me to resubmit, please let me know.
It's only a minor point about the correct spelling of RKI.

I am closing this PR since it conflicts with the merged PR #934 for the Czech Republic. Unfortunately git can't handle it well because the whole interoperability table is on one .json source line.

Hi @MikeMcC399, sorry I messed up your PR. I should have checked bevor. Go ahead, and submit a new PR. Thanks.

@dsarkar
No big problem. I've resubmitted as https://github.com/corona-warn-app/cwa-website/pull/937.


consider linking to buildbuddy to "Tooling" section

buildbuddy.io provides a UI for Bazel, and it's open source: https://github.com/buildbuddy-io/buildbuddy

Please feel free to open a PR.


minor update site.webmanifest

What type of PR is this?
minor update
What this PR does / why we need it:
add data for browser
Which issue(s) this PR fixes:
resolve https://github.com/karmada-io/website/issues/92

/assign @RainbowMango


Add 3D audio functionality to Music and Sound

In OpenAL a sound can have a 3D position and velocity. Being able to set these for Sound and Music would be great.
The function signatures would probably look something like this:
public void setSourcePosition(Vector3 position)
public void setSourceVelocity(Vector3 velocity)

As I know problem comes in portability. For example Android doesn't provide OpanAL and LibGDX uses native classes like MediaPlayer. And they come with very limited control over playback...

I'm afraid @metaphore is correct, we can't port spatial audio to anything but desktop systems.

@badlogic That's true, but may I ask why that is a problem?  There are certainly features that are only supported on Android and I would never argue that they shouldn't be there because of that. Of course, I understand that it's a good idea to not clutter the API with too many platform specifics, but that's not even the case here and I can certainly see those methods being useful on mobile platforms as well.
Only slightly related but Google's Cardboard SDK for Android will get spatial audio support.

We start with these 2 methods. Then users will want the full OpenAL feature set (if I added spatial audio I'd not be happy with just these two methods). The things explode and only work on desktop and users will complain.


Security Hardening

[ ] #112
[ ] #113
[ ] #114
[x] #139
[ ] Boot with signed kernels
[ ] Boot measurement

It might be worth adding #789 to this list.


Code changes for SNAP-2989: Snappy UI rebranding to Tibco ComputeDB iff it's Enterprise Edition

What changes were proposed in this pull request?

SnappyData is Community Edition

Displays Pulse logo on top left side.
Displays SnappyData logo on top right side.
About Box : Displays version and copyright information

TIBCO ComputeDB is Enterprise :

Displays TIBCO ComputeDB logo on top left side.
About Box  : - Displays version and copyright information

How was this patch tested?

Tested Manually

Please review http://spark.apache.org/contributing.html before opening a pull request.

LGTM. Please get the screenshots reviewed from all relevant folks.

Done.

All requested changes and feedback are taken care. Hence merging.


[BUG] Failed to read Parquet file generated by GPU-enabled Spark.

Describe the bug
An error below happened when I tried to read parquet file.
org.apache.parquet.io.ParquetDecodingException: Failed to read from input stream
The parquet file was generated by GPU-enabled Spark, and I tried to read it without GPU. When I used Spark with GPU, then there's no error.
Related logs including stacktrace are below.
20/07/10 03:42:41 WARN BlockManager: Putting block rdd_5_0 failed due to exception org.apache.parquet.io.ParquetDecodingException: Failed to read from input stream.
20/07/10 03:42:41 WARN BlockManager: Block rdd_5_0 could not be removed as it was not found on disk or in memory
20/07/10 03:42:41 ERROR Executor: Exception in task 0.0 in stage 1.0 (TID 1)
org.apache.parquet.io.ParquetDecodingException: Failed to read from input stream
        at org.apache.spark.sql.execution.datasources.parquet.VectorizedRleValuesReader.readNextGroup(VectorizedRleValuesReader.java:728)
        at org.apache.spark.sql.execution.datasources.parquet.VectorizedRleValuesReader.readInteger(VectorizedRleValuesReader.java:146)
        at org.apache.spark.sql.execution.datasources.parquet.VectorizedRleValuesReader.readIntegers(VectorizedRleValuesReader.java:549)
        at org.apache.spark.sql.execution.datasources.parquet.VectorizedColumnReader.readBatch(VectorizedColumnReader.java:228)
        at org.apache.spark.sql.execution.datasources.parquet.VectorizedParquetRecordReader.nextBatch(VectorizedParquetRecordReader.java:273)
        at org.apache.spark.sql.execution.datasources.parquet.VectorizedParquetRecordReader.nextKeyValue(VectorizedParquetRecordReader.java:171)
        at org.apache.spark.sql.execution.datasources.RecordReaderIterator.hasNext(RecordReaderIterator.scala:39)
        at org.apache.spark.sql.execution.datasources.FileScanRDD$$anon$1.hasNext(FileScanRDD.scala:93)
        at org.apache.spark.sql.execution.FileSourceScanExec$$anon$1.hasNext(DataSourceScanExec.scala:490)
        at org.apache.spark.sql.catalyst.expressions.GeneratedClass$GeneratedIteratorForCodegenStage1.columnartorow_nextBatch_0$(Unknown Source)
        at org.apache.spark.sql.catalyst.expressions.GeneratedClass$GeneratedIteratorForCodegenStage1.processNext(Unknown Source)
        at org.apache.spark.sql.execution.BufferedRowIterator.hasNext(BufferedRowIterator.java:43)
        at org.apache.spark.sql.execution.WholeStageCodegenExec$$anon$1.hasNext(WholeStageCodegenExec.scala:729)
        at org.apache.spark.sql.execution.columnar.CachedRDDBuilder$$anon$1.next(InMemoryRelation.scala:98)
        at org.apache.spark.sql.execution.columnar.CachedRDDBuilder$$anon$1.next(InMemoryRelation.scala:90)
        at org.apache.spark.storage.memory.MemoryStore.putIterator(MemoryStore.scala:222)
        at org.apache.spark.storage.memory.MemoryStore.putIteratorAsValues(MemoryStore.scala:299)
        at org.apache.spark.storage.BlockManager.$anonfun$doPutIterator$1(BlockManager.scala:1371)
        at org.apache.spark.storage.BlockManager.org$apache$spark$storage$BlockManager$$doPut(BlockManager.scala:1298)
        at org.apache.spark.storage.BlockManager.doPutIterator(BlockManager.scala:1362)
        at org.apache.spark.storage.BlockManager.getOrElseUpdate(BlockManager.scala:1186)
        at org.apache.spark.rdd.RDD.getOrCompute(RDD.scala:360)
        at org.apache.spark.rdd.RDD.iterator(RDD.scala:311)
        at org.apache.spark.rdd.MapPartitionsRDD.compute(MapPartitionsRDD.scala:52)
        at org.apache.spark.rdd.RDD.computeOrReadCheckpoint(RDD.scala:349)
        at org.apache.spark.rdd.RDD.iterator(RDD.scala:313)
        at org.apache.spark.rdd.MapPartitionsRDD.compute(MapPartitionsRDD.scala:52)
        at org.apache.spark.rdd.RDD.computeOrReadCheckpoint(RDD.scala:349)
        at org.apache.spark.rdd.RDD.iterator(RDD.scala:313)
        at org.apache.spark.rdd.MapPartitionsRDD.compute(MapPartitionsRDD.scala:52)
        at org.apache.spark.rdd.RDD.computeOrReadCheckpoint(RDD.scala:349)
        at org.apache.spark.rdd.RDD.iterator(RDD.scala:313)
        at org.apache.spark.rdd.MapPartitionsRDD.compute(MapPartitionsRDD.scala:52)
        at org.apache.spark.rdd.RDD.computeOrReadCheckpoint(RDD.scala:349)
        at org.apache.spark.rdd.RDD.iterator(RDD.scala:313)
        at org.apache.spark.scheduler.ResultTask.runTask(ResultTask.scala:90)
        at org.apache.spark.scheduler.Task.run(Task.scala:127)
        at org.apache.spark.executor.Executor$TaskRunner.$anonfun$run$3(Executor.scala:444)
        at org.apache.spark.util.Utils$.tryWithSafeFinally(Utils.scala:1377)
        at org.apache.spark.executor.Executor$TaskRunner.run(Executor.scala:447)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
        at java.lang.Thread.run(Thread.java:748)
Caused by: java.io.EOFException
        at org.apache.parquet.bytes.SingleBufferInputStream.read(SingleBufferInputStream.java:52)
        at org.apache.spark.sql.execution.datasources.parquet.VectorizedRleValuesReader.readUnsignedVarInt(VectorizedRleValuesReader.java:647)
        at org.apache.spark.sql.execution.datasources.parquet.VectorizedRleValuesReader.readNextGroup(VectorizedRleValuesReader.java:701)
        ... 42 more

Steps/Code to reproduce bug

Data preparation

Download Mortgage dataset from RAPIDS's official repo.

e.g.,

wget http://rapidsai-data.s3-website.us-east-2.amazonaws.com/notebook-mortgage-data/mortgage_2000-2001.tgz
tar xf mortgage_2000-2001.tgz

Note that this issue could be reproduced by at least 13k records. When using 12k records, the issue couldn't happen.
The example commands that I used to reduce the size of whole dataset are below.

cd mortgage_2000-2001/perf
head -13000 Performance_2000Q1.txt > Performance_2000Q1_13k.txt

Converting from CSV to parquet

Launching spark-shell with GPU: spark-shell --master local[*] --jars ${SPARK_CUDF_JAR},${SPARK_RAPIDS_PLUGIN_JAR} --conf spark.executor.memory=32g --conf spark.driver.memory=32g --conf spark.driver.memoryOverhead=4g --conf spark.executor.memoryOverhead=4g --num-executors 1 --conf spark.executor.cores=1 --conf spark.rapids.sql.concurrentGpuTasks=1 --conf spark.rapids.memory.pinnedPool.size=2G --conf spark.locality.wait=0s --conf spark.sql.files.maxPartitionBytes=512m --conf spark.sql.shuffle.partitions=10 --conf spark.plugins=com.nvidia.spark.SQLPlugin
Running scripts: https://gist.github.com/lazykyama/1b6831d4b7b6381ed4e2c9348f55aa5d#file-convert-scala

Reading parquet

Launching spark-shell without GPU: spark-shell --master local[*] --conf spark.executor.memory=32g --conf spark.driver.memory=32g --conf spark.driver.memoryOverhead=4g --conf spark.executor.memoryOverhead=4g
Running scripts: https://gist.github.com/lazykyama/1b6831d4b7b6381ed4e2c9348f55aa5d#file-read-scala

Expected behavior
No error happens when reading converted parquet file.
Environment details (please complete the following information)

Environment location: Standalone
Spark configuration settings related to the issue

Spark binaries are donwloaded by wget https://ftp.jaist.ac.jp/pub/apache/spark/spark-3.0.0/spark-3.0.0-bin-hadoop3.2.tgz
Spark itself is running on RAPIDS docker container: nvcr.io/nvidia/rapidsai/rapidsai:0.14-cuda10.2-runtime-ubuntu18.04
echo ${SPARK_CUDF_JAR} => /ws/rapids/jars//cudf-0.14-cuda10-2.jar
echo ${SPARK_RAPIDS_PLUGIN_JAR} => /ws/rapids/jars//rapids-4-spark_2.12-0.1.0.jar
Other env info:

OS: Ubuntu 18.04.3
CPU: Intel(R) Core(TM) i7-6850K CPU @ 3.60GHz
GPU: TITAN X (Pascal)

Additional context
N/A

I was able to reproduce the error.  I'll try to dig into what is happening now.

So when I use the official parquet tools on the file produced I get an error like
org.apache.parquet.io.ParquetDecodingException: Can not read value at 11809 in block 0 in file file:/home/roberte/src/rapids-plugin-4-spark/target/tmp.parquet/part-00000-9f03a80a-33f3-49ce-b796-69f9c90d5694-c000.snappy.parquet

Specifically it appears to be with
DOUBLE non_interest_bearing_upb
--------------------------------------------------------------------------------
*** row group 1 of 1, values 1 to 13000 ***

This looks like it is a cudf related bug, so I will file another issue there.

I filed the above issue in CUDF for this. Once it is fixed I will close this one.

The underlying CUDF issue was fixed in 0.15.  When I get a change I will try to verify that it is fixed for this use case, and if so then I will close this issue for the 0.2.0 release that will be based off of cudf-0.15

I was able to manually verify that this is fixed now.


Persisting valid DatePicker TimeField value

Closes #4033
The TimeField blur event doesn't happen when a TimeField is selected in a Popover (DateRangePicker) and the Popover is closed. To address that unmount related behavior the useDateField() hook was updated to be aware of valid times when segment updates occur.

This introduces behavior changes to DatePicker time granularity. Setting a valid time, before setting AM/PM, will set the time and trigger an onChange.
Previously a blur on the TimeField would have been needed to persist the time without setting AM/PM.
This change is general to TimeField.
If you test using the DatePicker "all the events" story, you'll see that the the change triggers two onChange events.

✅ Pull Request Checklist:

[x] Included link to corresponding React Spectrum GitHub Issue.
[ ] Added/updated unit tests and storybook for this change (for new code or code which already has tests).
[x] Filled out test instructions.
[ ] Updated documentation (if it already exists for this component).
[ ] Looked at the Accessibility Practices for this feature - Aria Practices

📝 Test Instructions:
Goto the default DatePicker story
Using story Controls, set granularity to hour, minute, or second.
Click on the button to open DatePicker Popover.
Select a date.
Scroll to the time field.
Enter a valid time up to the AM/PM.
Notice that your cursor on the AM/PM and the selected data and input time have been persisted to the DateRangePicker input.
If you tab away or close the Popover (by pressing escape or clicking outside the Popover) the value will persist.
Also test removing am/pm from the input as well as the TimeField in the Dialog, there is some code to prevent weird behavior around that.
It's worth regression testing TimeField and its events behavior.
🧢 Your Project:
RSP

I noticed a strange new behavior, when I delete the am/pm in the datefield (not in the popover, as that doesn't have Yihui's fix yet), and then left arrow to the closest segment, then arrow up/down to spin the time, then AM will automatically be selected again.

Correct, this is a behavior change that extends beyond TimeField in a DatePicker to all instances of TimeField and DateField. The change is that when we have a valid date and valid time (am/pm not set), we set the time and assume AM. The change is we do this on the last segment to create a valid date/time change rather than blur.

We've spent additional time looking at the sequence of events on popover close, why there are two events, using useEffect/useLayoutEffect, etc. Currently, we don't see a way forward with those approaches and we'd like to evaluate the desirability and feasibility of the behavior change.

From a blank field, selecting and editing values in the popover did not propagate to the blank field until I hit esc.

This behavior was noted in the this ticket. This is just how the current behavior is and not necessarily a result of this PR and will require additional work

hmm looks like there is a test failing


Receiver group.  Added receiver group, popover height adjustment

消息组，新增消息组，弹窗高度调整。
实际结果：

预期结果：

resolved


Support .NET Core 3.1

Summary of the issue
It's seems .NET Core 3.1 no longer been supported, right ?
Unable to update to v.1.9.1 in NUGET !
Environment
.NET Core SDK version:
Microsoft.EntityFrameworkCore version: 3.1.9
EFCoreSecondLevelCacheInterceptor version: 1.9.0

Exception message:
Severity	Code	Description	Project	File	Line	Suppression State
Error	NU1605	Detected package downgrade: Microsoft.EntityFrameworkCore from 5.0.0-rc.2.20475.6 to 3.1.9. Reference the package directly from the project to select a different version.
 R8.Lib.EntityFrameworkCore -> EFCoreSecondLevelCacheInterceptor 1.9.1 -> Microsoft.EntityFrameworkCore (>= 5.0.0-rc.2.20475.6)
 R8.Lib.EntityFrameworkCore -> Microsoft.EntityFrameworkCore (>= 3.1.9)	R8.Lib.EntityFrameworkCore	E:\Work\Develope\Asp\Ecohos\R8.Lib.EntityFrameworkCore\R8.Lib.EntityFrameworkCore.csproj	1

Full Stack trace:

It's seems .NET Core 3.1 no longer been supported, right ?
No.
If the TargetFramework of your project is netstandard2.0 or net461, EF Core 3.1 will be used. If the TargetFramework of your project is net5.0 or netstandard2.1, EF Core 5x will be used.

Sorry, currently I use Asp.NET Core 3.1. i wrote .NET Core 3.1 by mistake...
What you think about this ?

What's the TargetFramework of your R8.Lib.EntityFrameworkCore project?

Sorry, currently I use Asp.NET Core 3.1. i wrote .NET Core 3.1 by mistake...

I didn't want to make confliction between .NET Core for Windows and .Net Core for Asp Core
I mean, I use Asp Core. and <TargetFramework>netcoreapp3.1</TargetFramework>
But, I hadn't problem every time I updated your library.
But now, I don't know exactly what is the problem.
Maybe the problem is about the minimum version you set for dependencies ( .NET CORE 5 and EF CORE 5 )
Dependencies
.NETCoreApp,Version=v5.0
     Microsoft.EntityFrameworkCore (>= 5.0.0-rc.2.20475.6)
     Microsoft.EntityFrameworkCore.Relational (>= 5.0.0-rc.2.20475.6)

Try version 1.9.2. I added netcoreapp3.1 to the list of supported TargetFrameworks.

Thanks a lot. Now works like a charm ⭐


binggpt not function in window 11 from April 25

It doesn't work for me anymore whether portable or install version.

Me Too!
This cannot be used. When opened, it shows a blank screen. Is it possible that it has been blocked by Microsoft?

This is what I get no matter what lol. The other time it was about black holes.

white screen, same here.

edgeservices.bing.com
Our services aren't available right nowWe're working to restore all services as soon as possible. Please check back soon.

The same goes for mac os.

I get the same thing as stl3.
I hope it can be fixed.

Just tried it a minute ago and it worked fine.
Very strange

wasn't working for me using an Australian based IP address but worked fine when I connected to a UK based VPN server.
We can assume MS is being choosey about who gets access atm.

Same problem as @stl3 , i tried deleting all folders in AppData\Roaming and I can't get to the login screen.


make ProxyToServerConnection accessible for filters

Hi there,
I face the problem that I need to validate the body of a response together with the ChainedProxy used for the request. As far as I can see the only way to access the body is to use a HttpFilter (and a response buffer limit) and the only way to access the used ChainedProxy is through an ActivityTracker, but there seems to be no way to access both at the same time.
It is quite easy to hand down the ProxyToServerConnection to the HttpFilter, but it breaks the API. Is this something you would consider merging? Or is there a better way to access ChainedProxy?
Cheers, Lars

Since this is 2 years old, has conflicts, and hasn't been updated, I'll close this PR.


Making the Contact and Sign Up pages mobile responsive

🐛 Bug Report
The contact and sign in pages are not responsive with respect to a mobile view. The Contact page has unpleasantly sized input fields. The Sign Up page has content being hidden due to restrictive size of the parent element.
Relevant screenshots

I would like to work on this issue.

/assign

I have already made a PR. Kindly review it.


Actions erroneously return a timeout message when the command did not timeout.

Environment
Device and OS: System76 drap8
App version: v0.32.3
Kubernetes distro being used: any
Other: n/a
Steps to reproduce

Include an action command (like exit 1) that will fail right away without configuring maxTotalSeconds or maxRetries.
Run the associated Zarf command (i.e. zarf package create . for the below zarf.yaml):

kind: ZarfPackageConfig
metadata:
  name: actions-error-msg

components:
  - name: actions-error-msg
    actions:
      onCreate:
        before:
          - cmd: exit 1

Expected result
An error message like Failed to create package: unable to add component "actions-error-msg": unable to run component before action: command "exit 1" failed displays.
Actual Result
The error message Failed to create package: unable to add component "actions-error-msg": unable to run component before action: command "exit 1" timed out after 0 seconds displays.
Visual Proof (screenshots, videos, text, etc)

Severity/Priority
Medium
Additional Context
This causes confusion because people may be misled into believing that Zarf has timed out their command when it was the command that failed instead.

This ultimately comes from this code: https://github.com/defenseunicorns/zarf/blob/9402e828b6214223e832b1268900b1564c646adb/src/pkg/packager/actions.go#L164 which incorrectly assumes that if a timeout is reached it should display that message.  Something like this would be more appropriate:
select {
	case cfg.MaxTotalSeconds < 1 && cfg.MaxRetries < 1:
		// If we reached this point, the command failed to run without a timeout or retries
		return fmt.Errorf("command \"%s\" failed", cmdEscaped)

	case <-timeout:
		// If we reached this point, the timeout was reached.
		return fmt.Errorf("command \"%s\" timed out after %d seconds", cmdEscaped, cfg.MaxTotalSeconds)

	default:
		// If we reached this point, the retry limit was reached.
		return fmt.Errorf("command \"%s\" failed after %d retries", cmdEscaped, cfg.MaxRetries)
	}

Taking a look!


WIP Add mock API

Attempting to mock mailchimp subscribes for testing
Current issues:

getting Injector to replace the Mailchimp class with the MockMailchimp class

You can do this in the config.yml
eg.
Injector:
  Mailchimp:
    class: MockMailchimp

however I must be missing something regarding being able to Inject classes during test runs.

@tractorcow any ideas on how to switch out a class so we can mock reposes from Mailchimp and create some tests for this module? :)

Ended up using
 Config::inst()->update(
            'Injector',
            'Mailchimp',
            array('class'=>'MockMailchimp')
        );

in the setUp() of the test suite.


Extend register-tenant from page.simple instead of layout.simple

[x] Changes have been thoroughly tested to not break existing functionality.
[x] New functionality has been documented or existing documentation has been updated to reflect changes.
[x] Visual changes are explained in the PR description using a screenshot/recording of before and after.

I noticed that having a RegisterTenant page returned an error:
https://flareapp.io/share/v5pBZ6lP
After some debugging, I noticed that other "simple pages" were wrapped in an <x-filament::page.simple> instead of <x-filament::layout.simple> component. Changing this solved the error.
Before:

After:

Whoops, this slipped in during a refactor today.
Thanks for fixing, @rompetomp!


Added xaml styles

Use resourcedictionay to add styles
Fixes #96

@Depechie we were live streaming the PR and what we found is that Intellisense doesn't work from insides of the separate xaml resource file. It has to be in the App.xaml from what I found.....

Ok that makes sense! Shame about the intelligence though ;)

I will double check with the team.... maybe they fixed it in 2019 :)


[Feature][Agent] Support MQTT Source

Description
No response
Use case
No response
Are you willing to submit PR?

[ ] Yes, I am willing to submit a PR!

Code of Conduct

[X] I agree to follow this project's Code of Conduct

please assign it to me.

1, Agent implement, you can refer to:
https://inlong.apache.org/docs/next/design_and_concept/how_to_write_plugin_agent
2, InLong Sort Add a new Extract Node:
https://inlong.apache.org/docs/next/design_and_concept/how_to_extend_data_node_for_sort


update state logic with the new bridge protocol

Update of the relayer state change adapted to the new bridge protocol.

A check is failing, I think a rebase is needed.


Update log4j2 version for webapp.

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

8.9.1 is majorly for backend log4j upgrade, as we found a way to output logs with JNDI, but we should haven't this output in webapp. But I still upgrade it for master branch to avoid security scaner's warning.

OK, let me remove this.


Incompatibility with Iron's Spells and Spellbooks

This is a bit of an odd and niche issue because ISS nor any of its addons utilize ISS's WarlockAttackGoal by default, but I've come across this issue when utilizing KubeJS, KubeJS Iron's Spells, and EntityJS. When the WarlockAttackGoal is active, the mob's melee attacks do not utilize Better Mob Combat functionality.
If you need to test the script I'm using for it, please go ahead. It requires all the mods listed above. It goes in a .js file in the kubejs/server_scripts folder:
const $WarlockAttackGoal = Java.loadClass('io.redspace.ironsspellbooks.entity.mobs.goals.WarlockAttackGoal')

EntityJSEvents.addGoalSelectors('minecraft:husk', event => {
    event.arbitraryGoal(1, (e) => {
        return new $WarlockAttackGoal(e, 1, 40, 50, 2)
            .setMeleeBias(0.8, 0.8)
            .setAllowFleeing(false)
            .setSpells(
                [Spell.of('irons_spellbooks:firebolt'), Spell.of('irons_spellbooks:magic_missile')],
                [Spell.of('irons_spellbooks:slow')],
                [],
                []
            )
    })
})

https://github.com/user-attachments/assets/9642a4ec-bdae-40e1-bf50-1a7f31956cf8

I forgot to mention that I'm using a datapack for air punching. I'll list it here in a moment.

punch.zip
Here's the datapack.

Yeah, I haven't added any special support for their WarlockAttackGoal. I can add it.

Any news on this? I couldn't fix the issue myself.


Use instructions instead of questions for wikisql benchmark

Summary
This pull request updates the benchmarking strategy for our English SDK for Apache Spark. Previously, we were using WikiSQL as a benchmark and achieving an execution accuracy of 89%. While this is promising, it's not sufficient to claim that the SDK is ready for production use. This PR changes the benchmarking approach to generate SQL queries based on descriptive instructions rather than questions, aiming for a more accurate assessment of the SDK's capabilities.
Changes
Replace WikiSQL benchmark with a new benchmark that generates SQL queries from descriptive instructions.
Motivation
The previous benchmarking strategy using WikiSQL did not providing a clear enough picture of the SDK's performance and capabilities. By changing the benchmark to generate SQL queries from descriptive instructions, we aim to get a more accurate understanding of how well the SDK performs in real-world scenarios.

LGTM. Nice improvement! Do we want to share the new execution accuracy in PR description for future reference?


Bug: Errors are logged on debug level

Description
Errors are logged on debug
 INFO manifest_run{manifest="install"}: Step: The file ... contents needs to be linked from ... (Not printing initializers and finalizers yet)
DEBUG manifest_run{manifest="install"}: Atom failed to execute: File exists (os error 17)

Steps to reproduce
Have an existing symlink in the target location
Expected behaviour
Error message should not be logged with debug
Environment

OS Linux
Version: 0.7.4

Output is definitely something we want to improve. Thanks for raising this.

Merged in a PR. I think this particular issue was take care of previously, but I used it as an opportunity to check if in other places we are logging debug when it should be error. If there is any more places or instances where this happens, please open PR. Thank you!


How to implement interrupts

The device driver can be ignorant on how the interrupt is handled. Interrupt functionality can be limited to the conditions of the irq.
@dirbao explained in chat:

tldr today you can either
leave it up to the user, ask them to call a fn on irq
This requires explicit user action.
use async WaitForHigh/WaitForLow
This requires to go for embassy hal
try to come up with a non-async IrqPin trait, but there's been heaps of discussion about this in e-h and it hasn't happened because it's nontrivial (impossible?)
dunno.

Also, we need to expose interrupt sources outside the INT register, as here:
https://github.com/zephyrproject-rtos/hal_st/blob/master/sensor/stmemsc/iis3dwb_STdC/driver/iis3dwb_reg.c


Add Cohere Backend

Adds another REST backend for Cohere
Description
This PR adds a REST backend for Cohere's Co.Generate feature, which uses their Command model.
Types of change

New feature
Additional tests

Checklist

[x] I confirm that I have the right to submit this contribution under the project's MIT license.
[ ] I ran all tests in tests and usage_examples/tests, and all new and existing tests passed. This includes

all external tests (i. e. pytest ran with --external)
all tests requiring a GPU

[x] My changes don't require a change to the documentation, or if they do, I've added all required information.

Ok nice! Although the external tests are already passing in my local machine, I'd probably want to finish https://github.com/explosion/spacy-llm/pull/167 this first and have a proper test in our CI just to be super sure! Same goes for #157

Ok nice! Although the external tests are already passing in my local machine, I'd probably want to finish https://github.com/explosion/spacy-llm/pull/167 first and have a proper test in our CI just to be super sure! Same goes for https://github.com/explosion/spacy-llm/pull/157

We can also run the external test flow from GH in the Actions tab :slightly_smiling_face: Did that here for your branch, it passed. I don't think we need to wait for #167 in order to merge this - is this PR completely ready otherwise?

Ok if that's the case then the PR is ready! 🙇


[Question] RSA Decryption increases CPU usage by 0.1%

This is just something I've noticed, when I spam logging on the server my 16 cores AMD Ryzen 2700X CPU usage rises to 0.1%, even if it's a single logging attempt, imagine that it's over 300 players at a time spamming the login queue?

Thanks for the feedback! However, I'm closing this as it is not actionable for 2 reasons:

The BigInteger class responsible for RSA decryption was replaced by an industry accepted standard.

There is not enough information about the methodology followed in your test to suggest there is a change needed, or that effort needs to go into further optimization. If it becomes a problem it'll be looked into, but it doesn't sound like it at the time.


Move to fontawesome5

This pull requests has the code changes to move to fontawesome 5. See #19 for more details.
Closes #19.

Hm, it doesn't really work for me, need to do some research. But if it's better maintained we should switch.

Ah, it's due to the ugly folder structure, will merge and move the examples folder.


Reorganize api controllers

Created an '/controllers/api' folder to make it easier to add more
API's without putting all off them inside api.js. This is necessary
for the upcoming addition of the notification subscription API.

Fixed nit.


Pass query as prop with applyContainerQuery

Not a breaking change as it makes query in applyContainerQuery() optional.
Usage:
// Foo.js
const Foo  = ({ query }) => <Container query={query} />;
export default Foo;

// Container.js
const Container = ({ containerQuery }) => ...
export default applyContainerQuery(Container);

With this you can either use query as a param or as a prop. But on second thought, it might be more useful to merge the two. For example:
const finalQuery = { ...query, ...this.props.query }; This way, in the above example Container can have a base query and Foo can extend and override it.
// Foo.js
const query = {
  tablet: { maxWidth: 700 },
  desktop: { maxWidth: 1200 }
}
const Foo  = () => <Container query={query} />;
export default Foo;

// Container.js
const baseQuery = {
  mobile: { maxWidth: 399 },
  desktop: { minWidth: 400 }
};
const Container = ({ containerQuery }) => ...
export default applyContainerQuery(Container, baseQuery);

So the final applied query would be
{
  mobile: { maxWidth: 399 },
  tablet: { maxWidth: 700 },
  desktop: { maxWidth: 1200 }
};

What do you think?

Hi @GeKorm thanks for your PR! I don't quite get this at the first glance. Let me take a closer look tonight.

No worries! 1 more example to try to clarify: So before this PR you could only pass query as a prop using
// BEFORE
import { ContainerQuery } from 'react-container-query';

<ContainerQuery query={query}>
  {(params) => (

the box

  )}
</ContainerQuery>

This PR allows passing query as a prop using
// AFTER
import { applyContainerQuery } from 'react-container-query';

const BaseComponent =  = ({ containerQuery }) =>
;
const EnhancedComponent = applyContainerQuery(BaseComponent);

const AnotherComponent = () => (

    stuff
    <EnhancedComponent query={query} />

);

Finally with this comment, the query could be built by merging the query parameter and query prop. So applyContainerQuery's signature would be more like: applyContainerQuery(Component, baseQuery, initialSize?) -> ReactComponent(props = { query?, ...rest });
With the applied query being: const finalQuery = { ...baseQuery, ...this.props.query };
I have a working implementation (with tests) of the latter, if you'd like I can push that too.

I think this is a great idea. It would be useful if we can ignore query argument in applyContainerQuery and allow to specify it later in render function.
I also think we should merge the two query objects into one and process them together. But the thing that worries me is 1) this introduces more logical branches within the applyContainerQuery function; 2) who deep we should merge the query objects.
I suggest we can simplify things a little. What about we keep the applyContainerQuery the same, but when query is null or not provide, we will use the query props provided in render function. How does that sound? This way we don't have to merge objects.

Yep this is what I'm doing, checking query first.
So I just migrated a big project from css-element-queries to this library. I found what you said about merging to be true. However, even with the optional query param approach, the source wasn't always obvious; I always had to check if there was a parameter passed. In the end, in order to make things explicit, I went with a different approach.

Optional query param in applyContainerQuery
Optionally pass transformQuery, a function prop that takes query from above as an argument and must return a query

const query = {
  tablet: { maxWidth: 700 },
  desktop: { maxWidth: 1200 }
}

const addMobile = (baseQuery) => ({
  ...baseQuery,
  mobile: { maxWidth: 500 }
});

const BaseComponent =  = ({ containerQuery }) =>
;
const EnhancedComponent = applyContainerQuery(BaseComponent, query);

const AnotherComponent = () => (

    stuff
    <EnhancedComponent transformQuery={addMobile} />

);

// The final applied query will be
{
  tablet: { maxWidth: 700 },
  desktop: { maxWidth: 1200 },
  mobile: { maxWidth: 500 }
}

I'll push so you can check.

Closing this as it works just fine as a higher level render prop.


⚠ Bofrost.fr has degraded performance

In 4ea3245, Bofrost.fr (https://www.bofrost.fr) experienced degraded performance:

HTTP code: 200
Response time: 1485 ms

Resolved: Bofrost.fr performance has improved in cdb5568 after 9 minutes.


Remove unneeded advapi32 lib

Used to be needed when Rust sometimes relied on RtlGenRandom instead of BCryptGenRandom, but that changed as of https://github.com/rust-lang/rust/pull/84096
advapi32 is still used in Rust core, but only in the deprecated env::home_dir API, which we don't use:

https://github.com/rust-lang/rust/blob/22f8bde876f2fa9c5c4e95be1bce29cc271f2b51/library/std/src/sys/windows/c.rs#L681-L689
https://github.com/rust-lang/rust/blob/22f8bde876f2fa9c5c4e95be1bce29cc271f2b51/library/std/src/sys/windows/os.rs#L292
https://github.com/rust-lang/rust/blob/22f8bde876f2fa9c5c4e95be1bce29cc271f2b51/library/std/src/sys/windows/os.rs#L319
https://github.com/rust-lang/rust/blob/22f8bde876f2fa9c5c4e95be1bce29cc271f2b51/library/std/src/env.rs#L566-L575

Guess it is needed. I don't think we use env::home_dir anywhere, but maybe I don't understand our linking requirements well enough and std needs to link against advapi32 for the __imp_OpenProcessToken symbol (even though we don't use the one API that needs it) for... reasons


DRAFT - DOES NOT WORK

This is an attempt to create a JSM based IBM MQ kamelet sink

Superseded by #902


fix: Change Challenges copy and chapter 2 design

The PR closes #619 .

Is this ready for review?

No not yet


S3 as a Distributed Metadata Store

Description:
In the "Architecture" section, it states that in a clustered deployment, the metastore is typically a traditional RDBMS like PostgreSQL, which is the only supported option today.
However, in the "Distributed search on AWS S3" section, the metastore_uri is set to S3.
This raises the question: Is S3 also capable of being used as a distributed metadata store?
https://quickwit.io/docs/overview/architecture
https://quickwit.io/docs/get-started/tutorials/tutorial-hdfs-logs-distributed-search-aws-s3

S3 can be used as a metastore, but if you use it, you are required to ahve only one metastore service in your cluster (making it a SPOF)


For constraints, prefer leading/trailing to left/right.

While left/right is certainly OK, in general we want leading/trailing as that's generally what we're really after so we work correctly in both LTR and RTL scripts.  Yes, this is a breaking change, but it's minor enough.

I'm Jayson Lane and I approved this pull request.
:+1:

Merging, since we need to move forward. If there are further comments, we can come back and revisit this.


fix: don't filter out packages with dot in name

cc @pavelzw @jannikwibker
@pavelzw found a bug that accessing the UI with URLs like
http://our.domain.com/channels/local1/packages/package_name.with_dots
results in errors.
After a long search, we found the place responsible for this!
Not sure if this is the best fix, but it should filter out all package cases.

Thanks, @YYYasin19!
Could you pin pydantic on the dependencies? Here: https://github.com/mamba-org/quetz-frontend/blob/36e16e560b91b58290a2f8eaf2be6b69c86d6b37/setup.cfg#L31
That should fix CI.
Leaving this comment as documentation:
We are pining pedantic as a workaround until the fix is released upstream. See: https://github.com/mamba-org/quetz/pull/653


Broken links to "Receiving notifications"

Both the /sync response spec and the "Receipt" section link to https://matrix.org/docs/spec/client_server/latest#receiving-notifications as the "Receiving notifications" section, but its actual URL is https://matrix.org/docs/spec/client_server/latest#id91 (or #id81 on /unstable).

Dupe of #2623


s3 data validation: annotations

Add validation tests for annotations, some new, most of them ported over & refactored from Utz's @uermel tests. For a list of tests, see https://docs.google.com/document/d/1yMKM0DW9KRhlcYiBGPcR7oW0liGtUew6NAmBhMg5U3w/edit#heading=h.56ec9se80d6g
Also refactored data / file fetching to reflect that there is only one mrc / zarr file per segmentation mask annotation / tomogram / tiltseries. Note that in the metadata files, the mrc_files field in the path still is an list of strings and should get changed to be a single string (not done in this PR).

Closed, a later s3 data validation PR affected a lot of pieces this PR was intending to merge in, so will create a new refined PR


[ldd-vgr] <fds_scet_epoch_1-4 elements, times incorrectly fail pattern match validation>

Issue Type
Using the LABELS section to the right of this window >>>> , please indicate if this is a BUG or ENHANCEMENT request. If unknown, feel free to leave that blank and the LDD Steward can triage appropriately.
Describe the issue identified (if applicable)
When validating labels the fds_scet_epoch_1-4 fail the pattern match.  They should not fail, as their patterns do match the required pattern.
ERROR  [error.label.schema]   line 116, 33: cvc-pattern-valid: Value '1978-08-15T22:21:36.232776Z' is not facet-valid with respect to pattern 'YYYY-MM-DDTHH:MM:SS.SSSSSSZ' for type 'fds_scet_epoch_1'.
Describe the solution you'd like
Please update the LDD so that the error does not occur.
Describe alternatives you've considered
LDD Dictionary Version
PDS4 IM Version
1.16
Need-by Date
July 20, 2023
Additional context
Add any other context or examples products

@matthewtiscareno FYI, the <pattern> in the attribute definition is for a RegEx pattern. By setting it to YYYY-MM-DDTHH:MM:SS.SSSSSSZ, validate will only accept the literal string "YYYY-MM-DDTHH:MM:SS.SSSSSSZ", since none of those characters are symbolic/meaningful RegEx symbols (you'd need something like \d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}\.\d{6}Z to do this using a RegEx, and you'd need something even more complicated if you wanted to make sure month<=12, hour<=23, etc.).
It strikes me as probably better to just set the <value_data_type> to ASCII_Date_Time_YMD_UTC (or similar—these types validate the format of the value already) and omit the re-definition of <pattern> entirely.

Using the <value_data_type> ASCII_Date_Time_YMD_UTC sounds very reasonable to me.  I have no issues with omitting the pattern.


[k8sconfiguration] Fix bug in known_hosts property and add support for other key types

This checklist is used to make sure that common guidelines for a pull request are followed.

For new extensions:

[x] My extension description/summary conforms to the Extension Summary Guidelines.

About Extension Publish
There is a pipeline to automatically build, upload and publish extension wheels.
Once your PR is merged into master branch, a new PR will be created to update src/index.json automatically.
The precondition is to put your code inside this repo and upgrade the version in the PR but do not modify src/index.json.

If this PR is for a new extension or change to an existing extension, use the following to try out the changes in this PR:
docker run -it mcr.microsoft.com/azure-cli:latest
export EXT=<NAME>
pip install --upgrade --target ~/.azure/cliextensions/$EXT "git+https://github.com/jonathan-innis/azure-cli-extensions.git@master#subdirectory=src/$EXT&egg=$EXT"

k8sconfiguration

Missing an assignee and needing this to go under review

@fengzhou-msft This is done and updated based on comments, please merge ASAP


AnalysisException on empty .json file

I'm using Depensency Checker in the Jenkins plugin form, however this issue is present in the command line version.
Empty .json files are not handled gracefully, and throw an exception when the parser is trying to determine the encoding. Output in my case:
[DependencyCheck] Scanning: C:\Jenkins\workspace\SensitiveApplicationRedacted
[DependencyCheck] Analyzing Dependencies
[DependencyCheck] One or more exceptions were thrown while executing Dependency-Check
[DependencyCheck] Exception Caught: org.owasp.dependencycheck.analyzer.exception.AnalysisException
[DependencyCheck] Cause: Cannot auto-detect encoding, not enough chars
[DependencyCheck] Message: Failed to parse C:\Jenkins\workspace\SensitiveApplicationRedacted\node_modules\npmconf\test\fixtures\package.json file.
Some info on the source of the issue as per RFC 4627

JSON text SHALL be encoded in Unicode. The default encoding is
UTF-8.
Since the first two characters of a JSON text will always be ASCII characters [RFC0020], it is possible to determine whether an octet
stream is UTF-8, UTF-16 (BE or LE), or UTF-32 (BE or LE) by looking
at the pattern of nulls in the first four octets.
   00 00 00 xx  UTF-32BE
   00 xx 00 xx  UTF-16BE
   xx 00 00 00  UTF-32LE
   xx 00 xx 00  UTF-16LE
   xx xx xx xx  UTF-8

Thanks for the bug report!


Non-dollar Math supported by MathJax is not processed by MathJax-node

Markdown:
\begin{equation}
E = mc^2
\end{equation}

\begin{equation}
E = pc
\end{equation}

Command:
pandoc --mathjax -F pandoc-tex2svg

The resultant HTML is untouched by MathJax-node.
And by the way, the same test can be used to test AMS equation numbering. Because it is rendered by mj-single.js, I expect it not able to increment the numbering. I'm not sure what's the solution though (besides using mj-page.js which is supposed to work on HTML5 output. But obviously the one need this most is ePub output. I'm now thinking if it is possible to throw in the whole HTML file before combining it to ePub. However, I don't know the pandoc ePub build process so I don't know if it is possible.) I should have thought about this point before suggesting passing each equation to tex2svg rather than page2svg. I thought this is more robust, but now we lost AMS-numbering... Sorry!

Concerning applying page2svg on the individual .xhtml file extracted from ePub: it is a dead end, error on line 117 at column 16: Opening and ending tag mismatch: link line 0 and head keep popping up. I guess the XHTML confuses it.

This is really out of scope, since pandoc parses the equation environment as raw TeX and not as a Math element.  (For this reason, it won't work in any output format that doesn't know how to handle raw TeX.)
Ultimately pandoc needs to implement its own system for equation numbering, but that's another matter.


[Bug]: Dark mode for Plan a Trip page

Is there an existing issue for this?

[X] I have searched the existing issues

Describe the bug
The 'Plan a Trip' page currently has no styling changes between light and dark mode, resulting in a lack of visual consistency with the rest of the site. Updating this page to have distinct light and dark mode themes would improve user experience and visual coherence.
Expected behavior
When switching between light and dark mode, the 'Plan a Trip' page should adapt its styling accordingly:
In Dark Mode: Background, text, buttons, and other elements should follow the color scheme used throughout the site's dark mode. The text should remain readable against the darker background, and buttons and links should be styled with contrasting colors for easy visibility.
In Light Mode: Background, text, and buttons should align with the site’s light mode theme, with dark text on a lighter background for readability.
Add ScreenShots/Videos

On which device are you experiencing this bug?
Windows
Record

[X] I have read the Contributing Guidelines
[X] I'm a GSSOC'24 Extended contributor
[x] I'm a Hacktoberfest'24  contributor
[X] I have starred the repository

@apu52 i want to work on this issue. I am a KWOC24 contributor

@TheRGuy9201 welcome to the repo , I am assigning u the issue , start working on the issue 7 submit your PR.


fix(): updating the type of a & aaaa records field  to optional

To define aliases for A and AAAA records, the record field must be optional, allowing it to be omitted when necessary.

@microsoft-github-policy-service agree company="Microsoft"


How to expose envoy outside the localhost

Configured envoy as edge gateway using standalone exe, I can route and access the the https endpoints using localhost:PortNumber. I need to expose my localhost outside on the network so that other users on my domain access the endpoints. What configuration should I use to expose envoy-gateway on my localhost to the domain network?
static_resources:
  listeners:
  - name: listener_0
    address:
      socket_address:
        protocol: TCP
        address: <IP_ADDRESS>
        port_value: 5001
    filter_chains:
    - filters:
      - name: envoy.filters.network.http_connection_manager
    -  route_config:
     ---
         ----
          http_filters:
          - name: envoy.filters.http.router
      transport_socket:
        name: envoy.transport_sockets.tls
        typed_config:
          "@type": type.googleapis.com/envoy.extensions.transport_sockets.tls.v3.DownstreamTlsContext

I doubt anyone can answer this question. It depends on you network configuration and not on Envoy. You may need to do nothing or a lot depending on your situation.


In dhcp_compare2, add range comment to pool declarations

resolved by https://github.com/OSU-Net/cyder/issues/993


Don't know why I'm getting this error

Now it's openai_api_key

For help, please use Discord API Discussions or Discord Project Post
(Did you set that env variable?)

Yes


expected [string_array] got [string] - Move_group

Good evening!
I'm using ROS2 Humble and I'm working on a Lite6 project.
After installing Moveit2 from source and right after launching:

ros2 launch xarm_planner lite6_planner_fake.launch.py

I've noticed that the move_group node dies and so i can't perform the motion planning on my robot.

I was wondering what could I do to fix the error.
I've check on the moveit documentiation and see that:
"Warning: Most features in MoveIt will not work properly since additional parameters are required for full Move Group functionality. For a full setup, please continue with the [Move Group C++ Interface Tutorial]"
If anyone could give me advice on how to go through , I would be very pleased!
Thank you in advance,
Enrico

Make sure you follow the preparation and installation instructions from the xarm_ros2 readme file strictly
I had to reboot before being able to use the package (It could be the same issue but I do not remember)

I can actually use the package, the problem is that the parameters are not correct, I think that there are parameters that need to be set or unset in order to let the program correctly go through. Maybe it is just an installation mistake but i really doubt about it

You are using Ubuntu 22.04, right? Is it a fresh installation or have you used it for other developing purposes?
Did you succesfully run the moveit2 tutorials?
Did you try using the package post-reboot after the installation session?
I ran the command on my setup, you can check the CLI output. As you can see the error you mention is not there.

First of all, I appreciate your help! :D
I think there are problems with the planning_pipeline. I don't know yet how to solve this problem but I think there are issues with passing parameters to move group. For parameters I mean the planners, because I see that where my program crushes, yours instead say:

[move_group-4] [INFO] [1712390116.696721151] [moveit.ros_planning_interface.moveit_cpp]: Loading planning pipeline 'ompl'
[move_group-4] [INFO] [1712390116.723966080] [moveit.ros_planning.planning_pipeline]: Using planning interface 'OMPL'

So I really need to check how it is possible to fix that problem. Maybe it's a yaml problem? or maybe in the launch file? I am figuring out but if someone can help me I would really be grateful|

@Ep3896
Hello, could you provide the complete output of the terminal when running?

Of course! this is the log error: here
As for Rviz, this is the log on the window:

So the issue, I suppose, is that the planning pipeline yaml is not correct, but this is just my interpretation.
I really trying to understand how to fix that but without great outcomes yet.

@Ep3896
I compared it and found that you did not load the output related to planning_pipeline and the abnormality is that the type of a certain configuration parameter is wrong. Have you modified anything?

I don't think so!
However, I was able to point out where the program crashes:

ros2 launch xarm_moveit_config _robot_moveit_common.launch.py
this launche file gives me the error but I'm trying to figure out why

and my

@Ep3896
Running _robot_moveit_common.launch.py alone is incomplete. You can run lite6_moveit_fake.launch.py to find the problem.

ros2 launch xarm_moveit_config lite6_moveit_fake.launch.py

yes! but I have already run :

ros2 launch xarm_moveit_config lite6_moveit_fake.launch.py

But I have the exact same error!
Could it be libmoveit_planning_pipleline.so.2.9?
I'm running out of ideas, if you could provide to me, however your log of this:

ros2 launch xarm_moveit_config lite6_moveit_fake.launch.py

I would be really pleased :)
Thank you in advance!

@Ep3896
This kind of missing libmoveit_planning_pipleline.so.2.9 is usually caused by incomplete system updates. You may need to obtain updates from a stable source.
In addition, the humble version here is libmoveit_planning_pipleline.so.2.5.5, and the rolling version is libmoveit_planning_pipleline.so.2.9.0

@Ep3896
Maybe the problem lies in the libmoveit_planning_pipleline.so.2.9 version. This problem will also occur when I run it under the rolling version. I will look for the problem first.

@Ep3896
Hello, I looked through the moveit code and found that the configuration format has changed. Please refer to the pr for details.
You can temporarily modify the xarm_moveit_config/launch/_robot_moveit_common.launch.py file to use, we will fix this problem later.
Search for the definition of ompl_planning_pipeline_config, and then modify it to the following format
ompl_planning_pipeline_config = {
    'default_planning_pipeline': 'ompl',
    'planning_pipelines': ['ompl'],
    'ompl': {
        'planning_plugins': ['ompl_interface/OMPLPlanner'],
        'request_adapters': [
            'default_planning_request_adapters/ResolveConstraintFrames',
            'default_planning_request_adapters/ValidateWorkspaceBounds',
            'default_planning_request_adapters/CheckStartStateBounds',
            'default_planning_request_adapters/CheckStartStateCollision',
        ],
        'response_adapters': [
            'default_planning_response_adapters/AddTimeOptimalParameterization',
            'default_planning_response_adapters/ValidateSolution',
            'default_planning_response_adapters/DisplayMotionPath',
        ],
    }
}

Thank you very much!
I have learnt a lot :)
Greetings!

I have installed Moveit2 from the main branch because they textually say:

Currently the main branch supports Rolling, Iron, and Humble. However, since it’s used for latest development, the main branch is unstable. For stable versions, please use the distro branches humble, or iron.

And my goal is to actually keep up with the latest developments, even if they are unstable.
Btw, Thank you very much for helping me out!