private_repositories_indexed_here (spaces net, gateway (test), crates/knotless-serve/tests/gateway.rs) failed the pre-flight of every one of these pulls on 2026-11-07 and was logged FLAKY:
thread 'private_repositories_indexed_here' panicked at crates/knotless-serve/tests/gateway.rs:3490:5:
crates/knotless-serve/tests/gateway.rs:3490:5: waited 60s for what never held
Often it then passes (the logs also show it "running for over 60 seconds" on passing runs), so it sits right at its 60 s wait. Its earlier quarantine ran out on 2026-11-04 and the entry sat expired. It is quarantined again until 2026-11-14.
How to see it
Open any pull above and run knotless run list knotless://chadtmiller.com/knotless --pull <uri> --log, then search for private_repositories_indexed_here. It depends on load, so it shows under parallel runner load, on the spaces alpha.
What you expected
The wait to hold well inside 60 s.
Where
The runner (spaces net), main as of 2026-11-07.
Guess at the cause: the test shares a repository for writing with a newcomer, then waits for it to show in their search as they log in. That depends on the index hearing of the share from the space, which is asynchronous (a push rings no Jetstream, so it is picked up by polling the space). Under load the poll lands after the 60 s. Syncing the index explicitly in the test, as other tests do, would remove the race, and the wait should say which condition it waited on.
What happened
private_repositories_indexed_here(spaces net,gateway (test), crates/knotless-serve/tests/gateway.rs) failed the pre-flight of every one of these pulls on 2026-11-07 and was logged FLAKY:Each time:
Often it then passes (the logs also show it "running for over 60 seconds" on passing runs), so it sits right at its 60 s wait. Its earlier quarantine ran out on 2026-11-04 and the entry sat expired. It is quarantined again until 2026-11-14.
How to see it
Open any pull above and run
knotless run list knotless://chadtmiller.com/knotless --pull <uri> --log, then search forprivate_repositories_indexed_here. It depends on load, so it shows under parallel runner load, on the spaces alpha.What you expected
The wait to hold well inside 60 s.
Where
The runner (spaces net), main as of 2026-11-07.
Guess at the cause: the test shares a repository for writing with a newcomer, then waits for it to show in their search as they log in. That depends on the index hearing of the share from the space, which is asynchronous (a push rings no Jetstream, so it is picked up by polling the space). Under load the poll lands after the 60 s. Syncing the index explicitly in the test, as other tests do, would remove the race, and the wait should say which condition it waited on.