From 5e132977f4c5c3301a257b0b7cb7973ebb465f74 Mon Sep 17 00:00:00 2001 From: Lilleman auf Larv Date: Mon, 28 Sep 2026 01:48:32 +0200 Subject: [PATCH] Reflow the gate decision after the rename --- docs/decisions.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/decisions.md b/docs/decisions.md index c539e82..f71e77b 100644 --- a/docs/decisions.md +++ b/docs/decisions.md @@ -766,9 +766,9 @@ rule and an index of the titles below. `unbind()` takes through `now()`. 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. For the same reason the - retry in `carry()` asks `gate.awaitsNextLink()` rather than `canCarry()`, which also reads the socket — a - condition that loops on something the gate does not gate on spins against a gate that admits it - straight back. `LinkGate.returning` is a copy of `retrying()` taken at teardown, and stays true + retry in `carry()` asks `gate.awaitsNextLink()` rather than `canCarry()`, which also reads the + socket — a condition that loops on something the gate does not gate on spins against a gate that + admits it straight back. `LinkGate.returning` is a copy of `retrying()` taken at teardown, and stays true only because nothing stops the reconnect loop without `emitClose()` following it: `drain()` and `end()` are the only callers of `stop()`. A third caller has to shut the gate itself.