Files
alkhttp/tasks/websocket/review-001-ws-eof-signal.md
T
glm-5.3-flash 12b35e2c5f docs(tasks): decompose review 001 remediation Units 1-5 into taskgraph tasks
21 review-001 tasks across server/adapters/client/gateway/websocket/infra,
chunked from the 7-unit remediation plan in
docs/reviews/001-initial-implementation-review.md.

- Scope split by mechanism, not one-per-finding: 15 tasks in generation 1
  (parallelizable), 6 sequenced after their file-sharing precursors
- Deliberately deferred until dependent fixes land: projection/doc
  fidelity partial (Unit 6 beyond dependency hygiene), coverage backfills
  (COV-01..07 via in-task acceptance for forward.rs), and per-finding
  minors (OAI-06/07, HY-02/04/06/10/11, CON-08)
- Cross-crate WS-12 (alkcall demux 4 GiB discard alloc) noted for filing
  in alkcall, not here

taskgraph: validate clean, no cycles, 6 generations
2026-08-29 07:10:15 +00:00

2.7 KiB

id, name, status, depends_on, scope, risk, impact, level, tags
id name status depends_on scope risk impact level tags
review-001-ws-eof-signal Lossless EOF signal + pending-map sweep for from_wss (WS-02, CON-02) pending
narrow high component implementation
websocket
adapters
review-001
from-wss

Description

Review 001 findings WS-02 + CON-02 — one mechanism, verified end-to-end:

src/websocket/byte_adapter.rs:138-139 (and the tungstenite twin at :319) fires read_eof.notify_waiters(), which wakes only already-registered waiters and stores no permit. from_wss spawns its drop-monitor after session setup (from_wss.rs:156-166); if the read task hits EOF before the monitor first polls Notified, the signal is lost. import() does std::mem::forget(session) (:193), so the close_rx fallback never fires either — the monitor never runs fail_all, and in-flight imported-op calls hang (Once-calls recover only at the 30 s sweeper if a sweeper runs; CON-02 establishes it doesn't on this path — Dispatcher::run_loop's sweeper is never taken; Sub/Pub pendings hang forever). The module doc at from_wss.rs:111-113 promises the opposite of the behavior.

Fix both halves:

  • Replace notify_waiters with a permit-storing signal: tokio::sync::watch, CancellationToken, or a checked AtomicBool — anything a late subscriber observes. Apply to both the axum and tungstenite pump paths.
  • Extend the from_wss monitor to sweep the pending map periodically while the session lives (or otherwise ensure post-fail_all registrations still resolve), since calls registered after the one-shot fail_all are currently never resolved.

Acceptance gates from the review: (1) a from_wss test that drops the connection while a call is being registered — the CON-02 race — with no hang; (2) the module doc's promise ("no hang") becomes true.

Acceptance Criteria

  • EOF-notify is stored (late subscriber observes it) — race test: drop during session setup/first call registration resolves all in-flight calls as retryable
  • Post-fail_all-registered pendings also resolve (sweep or equivalent), not hang forever
  • The connection_drop_fails_in_flight_calls_retryable_no_hang test remains green; add the racing-drop variant (COV gap 10)
  • Module doc at from_wss.rs:111-113 matches implemented behavior
  • cargo test and cargo clippy --all-targets -- -D warnings pass

References

  • docs/reviews/001-initial-implementation-review.md (Part B, WS-02; Part G, CON-02; COV-03)
  • docs/architecture/decisions/070-from-wss-consumer-adapter.md

Notes

Agent fills during implementation. Highest-priority WS fix — lossy notification hangs calls; everything else in the WS subsystem can follow.

Summary

Filled on completion.