[PRINCEKK122]

Closes #181.

Problem

FromTcpThreadMessage declares four variants and update.rs handles all four, but the TCP thread only ever constructed Disconnected, added by #179. Connected, Sent and SendError were dead arms.

Two consequences, both from the issue:

1. The throughput indicator has never displayed. on_tcp_packet_sent is reachable only from the Sent arm, so show_metrics stayed false forever and metrics_block early-returned an empty widget every frame. The whole metrics subsystem — packets_last_60s, bps, sent_packet_times, human_bps — was unreachable, so Add a status indicator to the Relay GUI that shows packet transfer rate over TCP #109's acceptance criteria were never actually met in shipped code.
2. The status line was stale. tcp_connected was only ever assigned by the Check TCP Connection Status button, so the GUI could read false while packets were actively reaching the listener.

Change

• Connected is reported from the Ok arm of TcpStream::connect, mirroring what the Err arm already does with Disconnected.
• Sent(bytes) is reported from try_send, the single funnel all three packet-shape branches (4-field, 8-field, paired) pass through, so every path is covered without duplication. send_packet_and_debug writes exactly packet.as_bytes(), so pkt.len() is the honest byte count.
• SendRaw reports too — a test packet is still a packet on the wire.
• Write failures propagate. The fan-out discarded every result (let _ = try_send(...), eight times). It now uses ?, and a failure reports Disconnected and exits the thread.

Why a write failure is a disconnect

A broken connection doesn't fail one packet, it fails all of them: six to eight per baton tick at 20 Hz. Reporting each one would write ~120 entries/sec into the event log and bury everything else in the five-line GUI panel — the bug #183 just fixed. Treating it as a disconnect instead reuses the recovery path #179 established, which calls reap_tcp_thread() so Connect TCP works again without pressing Disconnect TCP first.

SendError is left in the enum, documented as unconstructed, for a future transient-failure case that can be reported without tearing the connection down.

Testing

Two tests added to update.rs, using the existing pump_update harness so they drive the same Message::Update the GUI subscription sends:

• connecting_reports_status_without_a_manual_check — binds a real listener, connects, accepts, and asserts tcp_connected becomes true with no button press.
• sent_packets_make_the_throughput_block_appear — sends a packet over a real socket and asserts packets_last_60s > 0 and show_metrics, the flag that gates the throughput block.

cargo test passes, 10/10. Warning count is unchanged from main.

Also verified manually on Linux against src/server/ with the baton driven at the plugin's 20 Hz: the status flips on its own and the throughput block appears.

[Sanjana-Siddani]

Nice fix! All tests pass, and I also tested iMotions closing the connection mid-stream. The banner showed the error, the event log got just one entry instead of a flood, and reconnecting worked right away without pressing Disconnect first. Approving

[PRINCEKK122]

@Sanjana-Siddani this was approved on Oct 18, but #247 landed in the meantime and I pushed a merge commit to resolve the conflict in relay/src/state.rs, which dismissed the approval. The only new content is the conflict resolution: the Send arm now mirrors every packet to the Python mirror regardless of whether the iMotions write succeeded, since the mirror is a separate destination and shouldn't lose a copy because iMotions went away. The #181 changes themselves are unchanged. Could you take another look?

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud