jsii release 1.86.0 is breaking our tox tests #4207
Assignees
Labels
Comments
dreambeyondorange
added
bug
This was referenced Aug 2, 2023
|
We are also encountering the same issue for tests that are running in parallel, with each test running The fix of pinning to 1.85.0 also worked for our use case. |
|
v1.86.0 broke pytest-xdist. @aamielsan fix of pinning v1.85.0 worked here. thanks! one of the errors:: |
|
seeeing the same issue with our CD pipelines. @aamielsan fix also worked for us |
|
Per the PR notes on #4181, this release makes a change to the runtime package caching, swapping from an opt-in default to an opt-out. This caching is what seems to be causing parallelized workflows (i.e. tests) to fail. As an alternative workaround to being stuck on |
rix0rrr
added a commit
that referenced
this issue
Aug 9, 2023
The package cache mechanism that was turned on by default in #4181 works in theory under parallelism, but not in practice. Typically the CDK CLI will prevent CDK apps from running in parallel, but Python testing frameworks like `tox` use subprocess parallelism to speed up test runs, leading to the jsii imports being executed at the same time. Since jsii is sync, the locking needs to be sync. The sync locking feature of the `lockfile` library doesn't have wait support (for good reason), and so when a lock is already acquired by another process it quickly burns through its 12 retries in a hot loop, and then exits with an error. Two changes to address this: - (Ab)use `Atomics.wait()` to get a synchronous sleeping primitive; since `lockSync` doesn't support synchronous sleep, we build our own retry loop with synchronous sleep around `lockSync`. - Since the extracted directory is immutable: if the marker file in the extracted directory exists, we can treat it as evidence that the directory has been completely written and we can skip trying to vy for exclusive access to write it. This avoids all lock contention after the very first CDK app execution. Fixes #4207.
mergify bot
pushed a commit
that referenced
this issue
Aug 10, 2023
The package cache mechanism that was turned on by default in #4181 works in theory under parallelism, but not in practice. Typically the CDK CLI will prevent CDK apps from running in parallel, but Python testing frameworks like `tox` use subprocess parallelism to speed up test runs, leading to the jsii imports being executed at the same time. Since jsii is sync, the locking needs to be sync. The sync locking feature of the `lockfile` library doesn't have wait support (for good reason), and so when a lock is already acquired by another process it quickly burns through its 12 retries in a hot loop, and then exits with an error. Two changes to address this: - (Ab)use `Atomics.wait()` to get a synchronous sleeping primitive; since `lockSync` doesn't support synchronous sleep, we build our own retry loop with synchronous sleep around `lockSync`. - Since the extracted directory is immutable: if the marker file in the extracted directory exists, we can treat it as evidence that the directory has been completely written and we can skip trying to vy for exclusive access to write it. This avoids all lock contention after the very first CDK app execution. Fixes #4207. --- By submitting this pull request, I confirm that my contribution is made under the terms of the [Apache 2.0 license]. [Apache 2.0 license]: https://www.apache.org/licenses/LICENSE-2.0
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
When we run tox, we get the following error
See our github actions log https://github.com/aws/aws-parallelcluster/actions/runs/5734849633/job/15541683710?pr=5553
Pinning the version allows it to succeed aws/aws-parallelcluster#5555
Expected Behavior
jsii to not fail
Current Behavior
jsii fails due to a lock file already existing
Reproduction Steps
steps are performed in this github action https://github.com/aws/aws-parallelcluster/actions/runs/5734849633/job/15541683710?pr=5553
Possible Solution
No response
Additional Information/Context
No response
SDK version used
1.204.0
Environment details (OS name and version, etc.)
Ubuntu 22.04.2
The text was updated successfully, but these errors were encountered: