caseworkctl public_jwks test can fail when another test takes its port
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 84/100
- Issue type
- Bug
- Clarity
- Clearly specified
- Activity status
- Active
- Tech stack
- rust
- Domain
- testing-qa
Research direction
Start in crates/registry-caseworkctl/src/dev/public_jwks.rs at dev::public_jwks::tests::serves_only_public_keys_and_releases_its_listener, and inspect how the ephemeral port and release probe are handled. Run the named test with parallel cargo test. Done means the release assertion no longer fails because another test temporarily occupies the selected port, while still verifying that the server releases its listener.
Written by the indexing model from the issue text.
Description
dev::public_jwks::tests::serves_only_public_keys_and_releases_its_listener in crates/registry-caseworkctl/src/dev/public_jwks.rs failed once in the Rust workspace job on 2026-09-27, on a PR that changed no Rust code:
panicked at crates/registry-caseworkctl/src/dev/public_jwks.rs:159:21:
`Result::unwrap()` on an `Err` value: the explicit public JWKS port is occupied
caused by: Address already in use (os error 98)
A re-run passed.
Suspected cause (not reproduced; about 70% confident)
The test picks a port by binding 127.0.0.1:0 and dropping that listener, starts the server on the port, then after drop(server) calls probe(port) to prove the listener was released. Under parallel cargo test, another test can bind the same ephemeral port in either gap, so the release check fails even though the server did release it.
Fix direction
Test-only. Make the release assertion independent of other processes on the machine, for example by retrying the probe briefly, or by asserting on the server's own socket rather than on the port being free. The production code path is not implicated.
- Dominant language
- Rust
- Stars
- 2
- Forks
- 0
- Avg merge
- 7h 46m
- Merged PRs (30d)
- 199
Getting set up
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from registrystack/registry-stack
-
area:breg criticality:p3 documentation triage:needs-implementation
Difficulty 1/5 Under an hour Newbie friendliness 86/100
registrystack/registry-stack#1713 ·
Maintainers usually reply within 1 day
-
area:breg bug criticality:p3 triage:needs-implementation
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
registrystack/registry-stack#1699 ·
Maintainers usually reply within 1 day
-
area:breg bug criticality:p3 triage:needs-implementation
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
registrystack/registry-stack#1682 ·
Maintainers usually reply within 1 day
-
area:casework bug criticality:p3 triage:needs-implementation
Difficulty 1/5 Under an hour Newbie friendliness 88/100
registrystack/registry-stack#1669 ·
Maintainers usually reply within 1 day
-
area:evidence bug criticality:p3 triage:needs-implementation
Difficulty 2/5 1-3 hours Newbie friendliness 86/100
registrystack/registry-stack#1665 ·
Maintainers usually reply within 1 day
All issues in registrystack/registry-stack
Similar issues
-
area: dogs area: lookout bug security
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
Maintainers usually reply within 1 day
-
Difficulty 1/5 Under an hour Newbie friendliness 92/100
Maintainers usually reply within 2 days
-
documentation
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
OpenDevicePartnership/ina4230#31 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
posit-dev/ggsql#565 · 1 reaction ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 1 day