Name what each of the three request paths skips
Test / test (22) (pull_request) Successful in 32s
Test / test (24) (pull_request) Successful in 32s
Mirror / push (push) Has been cancelled
Test / test (26) (pull_request) Successful in 32s
Test / lint (pull_request) Successful in 23s
Test / test (18) (pull_request) Successful in 32s
Test / test (20) (pull_request) Successful in 32s

This commit is contained in:
2026-09-28 10:25:08 +02:00
parent 469a91b9bb
commit b4bb531200
4 changed files with 13 additions and 14 deletions
+1 -1
View File
@@ -772,7 +772,7 @@ rule and an index of the titles below.
`OutgoingRequests.canCarry()` reads it rather than `closed`. The gate is told what happened and
never reads back into the session: a collaborator that has to ask does not own its decision, which
is how the first cut ended up answering the same question two different ways at admit and at
release. The retry in `carry()` asks `gate.awaitsNextLink()` rather than `canCarry()`, which also
release. The retry in `requestPastDrain()` asks `gate.awaitsNextLink()` rather than `canCarry()`, which also
reads the socket: a loop condition the gate does not gate on spins against a gate that admits it
straight back.