chadtmiller.com/knotless
git that lives in your Atmosphere account
Two forge tests wait for the appview to hear another account's write
MergedThis adds two wait_until calls to forge.rs so the tests wait for the appview to hear a write before reading it as another account.
assignees_and_reviews_maintainers_ask_for: it now polls the author'sshowfor\nreview requested: {theirs}\nbefore the author'sask-review. That matches the linecli.rsprints, and it is the same pattern the nearbyassignees:wait already uses. At that point the owner's ask is the only one, so the exact-line match is safe.maintainers_dismiss_reviews:assert!(blocked(&owner))becomeswait_until(|| blocked(&owner)). It is the same fix as the one the test already uses after the first review.
I read the diff and the surrounding test code but did not run the tests. CI is the only check, as the body says. The waits are bounded, so a real failure would still show as a timeout panic.
Round 2. The earlier approval was at cf51e35. The head now adds a "retry the read" commit and a merge of main, and the diff has changed shape since that review:
assignees_and_reviews_maintainers_ask_for: the author'sask-reviewis now retried until its answer equals{mine}\n{theirs}. Asking again for a reviewer already asked changes nothing, so retrying is safe, and the wait is bounded. This is simpler than the earliershowpoll.maintainers_dismiss_reviews: the test waits for, dismissed\ninshowbefore asserting on it, and theblocked(&owner)assertion becomes a wait. Both read another account's write through the appview.
I read the diff and the wait_until helper but did not run the tests, so CI is the check. One thing to watch: the final assert!(!blocked(&owner)) after the collaborator's dismissal still reads another account's write without a wait. It could flake the same way, though it's outside what this pull claims to fix.
crates/knotless-serve/tests/forge.rsline 2456
ok(&bot, &["comment", &url, &pull, "Still not", "--changes"]); | |
wait_until(|| blocked(&owner)); | |
ok(&collab, &["dismiss", &url, &pull, gate, "Fine by me"]); | |
assert!(!blocked(&owner)); |
This reads the collaborator's dismissal as the owner with no wait, so it can flake like the cases fixed above. Consider wait_until(|| !blocked(&owner)).
8 passed, 2 skipped
What changes
Two tests in
crates/knotless-serve/tests/forge.rswait for the appview to hear of a record before reading it as another account:assignees_and_reviews_maintainers_ask_for: the author'sask-reviewanswers who is asked now, read through the appview. It waits untilshowlists the owner's ask before asserting that the answer includes it.maintainers_dismiss_reviews: after the gate reviews again,merge --checksees the new review only once the appview has it. The test now waits for it, as it already did for the first review.Why
Both failed on main at 1b7d479, on both tries, over the spaces PDS: one expected two reviewers and got one, and the other found the pull not blocked. The same tree passed on the pull's own run, on a quieter host. Neither is a fault in the code: a record another account wrote a moment ago is not read yet. Until
testpasses on main, nothing deploys, and every batch built on it fails the same way.How it was checked
Left to CI: the two tests run in
test's forge binary on both nets.🤖 Generated with Claude Code