alkhttp/tasks/websocket/review-001-ws-pump-consolidation.md at 12b35e2c5f8bb16217d937296ca6df9135318843

Files

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.4 KiB

Raw Blame History

id, name, status, depends_on, scope, risk, impact, level, tags

name

status

depends_on

scope

risk

impact

level

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.

2.4 KiB Raw Blame History Unescape Escape