Have drop() name the event a lost link warrants, and name requestOnCurrentLink() for what it does

2026-09-28 21:31:48 +02:00
parent 2152b995d4
commit fe320d23a8
5 changed files with 27 additions and 17 deletions
@@ -201,13 +201,22 @@ next work ([decision](docs/decisions.md#internals-and-tests)).

 A second four-seat run on 2026-09-28, after #35–#40, read 6, 6, 7 and 6 again, Locality 5, 5, 6
 and 5. Every seat ranked the session's lifecycle hardest and least wanted to modify it. A third,
-after #46, read 6, 6, 7 and 7, Locality 5, 5, 6 and 6; the link's liveness now has one owner.
+after #46, read 6, 6, 7 and 7, Locality 5, 5, 6 and 6. A fourth, after the link's liveness got one
+owner in #48, read 6, 6, 6 and 6, Locality 5 from every seat: all four still ranked `Session.teardown()`
+hardest, and the held-message flow across `incoming-requests.ts`, `held-messages.ts`, `sms.ts` and
+`Session`'s rejection handler second.

 - [ ] **Lift Locality to 7, and confirm it with a scoring run.** A run reading 7.0 or above also
      retires the #30 and #46 decision.

 ### Correctness

+- [ ] **Register a multipart send's receipt merge before its segments go out.** `Session.sendSms()`
+      calls `dlrMerger.expect()` only once `submitSms()` resolves, after the last segment's response,
+      so a receipt for an early segment that arrives first is logged at `debug` as naming no merge,
+      and the group then waits out `dlrMergeTimeout` with no `messageDlr`. Likeliest with a fast SMSC
+      or more segments than `maxOutstanding`. Goal 2. From the 2026-09-28 scoring run on #48.
+
 - [ ] **Settle what a repeated tag not marked `multiple` reads as, and pin it in a test.** A vendor
      tag or a known single-value tag a peer sends twice keeps the last occurrence and drops the
      rest silently, which goal 3 argues against; listing it would change every such tag's shape.