Files
alkhttp/tasks/websocket/review-001-ws-pump-consolidation.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

58 lines
2.4 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
---
id: review-001-ws-pump-consolidation
name: Dedupe pumps + byte-based caps + write-side validation (WS-11, WS-04, WS-05, WS-06, HY-09)
status: pending
depends_on: []
scope: moderate
risk: medium
impact: component
level: implementation
tags: [websocket, review-001]
---
## Description
Review 001 findings where the correct fix is restructuring the duplicated
pump code in `src/websocket/byte_adapter.rs`, so they are done once
instead of twice (axum path `:119-180`, tungstenite twin `:299-364`):
- **WS-11**: ~60 lines of pump logic (read task, write task, close
handling) are copy-pasted between the axum and tungstenite paths while
the module doc claims "one implementation, both directions". Factor
over a generic sink/stream of messages. This also closes COV-03 (the
tungstenite twins are untested).
- **WS-04 + HY-09**: the write-side chunk parser does no length
validation (`:161-163`, twin `:343-345`) — non-chunk-framed bytes make
the parser silently wait to accumulate `8 + len` (up to ~4 GiB) from
misaligned offsets. Validate `len > MAX_CHUNK_LEN` → fail the stream
loudly; saturating add for the 32-bit overflow.
- **WS-05**: the write-side `pending` buffer is bounded in slots (64) but
not in bytes (~1 GiB worst case per connection with a slow sink).
Cap `pending` growth in bytes.
- **WS-06**: inbound per-connection memory bound is 64 slots × 64 MiB
(axum/tungstenite defaults) ≈ 4 GiB — `max_message_size`/
`max_frame_size` are never configured. Set explicit caps consistent
with the plan's ~1 MiB write-side intent.
## Acceptance Criteria
- [ ] Pump bodies factored into one generic implementation (both paths share it)
- [ ] Write-side rejects `len > MAX_CHUNK_LEN` with a stream error (test); no `8 + len` overflow path
- [ ] Write `pending` byte-capped; inbound message/frame size explicitly configured (tests)
- [ ] Tungstenite path exercised by the shared test suite (COV-03 backfilled)
- [ ] 16 MiB round-trip and disconnect-cleanup tests still pass
- [ ] `cargo test` and `cargo clippy --all-targets -- -D warnings` pass
## References
- docs/reviews/001-initial-implementation-review.md (Part B, WS-04, WS-05, WS-06, WS-11; HY-09; COV-03)
## Notes
> Agent fills during implementation. Sequenced with (or after)
> review-001-ws-eof-signal so the dedup doesn't churn under it — both
> touch byte_adapter.rs.
## Summary
> Filled on completion.