You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
crates/fbuild-daemon/src/handlers/websockets.rs::handle_serial_ws() was refactored in #750 from a single tokio::select! loop into three concurrent tasks (reader / writer / inbound). The split has no test coverage — landed on hardware validation only.
What needs covering
Unit tests (in-process, mock channels)
Reader contract: given a stream of SerialStreamEvents on the broadcast channel, the reader pushes one SerialServerMessage::Data per Data event into the out-mpsc, and forwards non-Data events 1:1.
Writer batching: when N Data messages are already queued in the out-mpsc before the writer wakes up, the writer coalesces them into a single Data { lines: [...], current_index: ... } WS frame.
Writer event-ordering: when a non-Data message arrives mid-batch, the writer flushes the pending Data batch FIRST, then ships the non-Data event, then continues batching new Data.
Writer exit propagation: when the WS sink returns an error, the writer exits cleanly without panicking; the reader and inbound tasks notice (out-mpsc producers dropped → next send fails or recv returns None).
RecvError::Lagged at the reader: the broadcast receiver lag path emits a tracing::warn! and continues; doesn't kill the reader task.
Slow socket: artificially delay the WS sink (e.g. wrap it in a tokio::time::sleep(10ms) layer); confirm the reader keeps draining the broadcast channel and the writer ships bigger batches as the queue grows. Asserts the producer/consumer decoupling.
Mixed traffic: interleave Data events with PortDisconnected / PortReattached events; assert FIFO ordering at the client.
Suggested file layout
crates/fbuild-daemon/src/handlers/websockets.rs — keep production code clean; add #[cfg(test)] mod tests { ... } at bottom for unit tests that can drive the reader/writer functions in isolation (this means extracting them into testable free functions — a useful refactor in its own right).
crates/fbuild-daemon/tests/serial_ws_burst.rs — integration tests spinning up a real daemon and WS client.
Acceptance criteria
All new tests pass under soldr cargo test -p fbuild-daemon.
Sub-issue of #755 (post-#750 follow-up meta).
Scope
crates/fbuild-daemon/src/handlers/websockets.rs::handle_serial_ws()was refactored in #750 from a singletokio::select!loop into three concurrent tasks (reader / writer / inbound). The split has no test coverage — landed on hardware validation only.What needs covering
Unit tests (in-process, mock channels)
SerialStreamEvents on the broadcast channel, the reader pushes oneSerialServerMessage::DataperDataevent into the out-mpsc, and forwards non-Data events 1:1.Datamessages are already queued in the out-mpsc before the writer wakes up, the writer coalesces them into a singleData { lines: [...], current_index: ... }WS frame.recvreturnsNone).RecvError::Laggedat the reader: the broadcast receiver lag path emits atracing::warn!and continues; doesn't kill the reader task.Integration tests (real daemon, real WS client)
rx.sendburst, attach a WS client, assert all 320 lines arrive (noLaggedwarnings, no drops). This is the exact reproducer for perf(serial): per-line WebSocket messages drop lines under sustained TX bursts #749.tokio::time::sleep(10ms)layer); confirm the reader keeps draining the broadcast channel and the writer ships bigger batches as the queue grows. Asserts the producer/consumer decoupling.Dataevents withPortDisconnected/PortReattachedevents; assert FIFO ordering at the client.Suggested file layout
crates/fbuild-daemon/src/handlers/websockets.rs— keep production code clean; add#[cfg(test)] mod tests { ... }at bottom for unit tests that can drive the reader/writer functions in isolation (this means extracting them into testable free functions — a useful refactor in its own right).crates/fbuild-daemon/tests/serial_ws_burst.rs— integration tests spinning up a real daemon and WS client.Acceptance criteria
soldr cargo test -p fbuild-daemon.Cross-links