Skip to content

Issue #181 solved: report TCP connect and send status to the GUI - #234

Open
PRINCEKK122 wants to merge 2 commits into
oss-slu:mainfrom
PRINCEKK122:181-tcp-thread-status
Open

PRINCEKK122 wants to merge 2 commits into
oss-slu:mainfrom
PRINCEKK122:181-tcp-thread-status

Conversation

@PRINCEKK122

Copy link
Copy Markdown
Contributor

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.

FromTcpThreadMessage declared four variants and update.rs handled all
four, but the TCP thread only ever constructed Disconnected, added by
oss-slu#179. Connected, Sent and SendError were dead arms.

Two things were broken by that. tcp_connected was only ever assigned by
the Check TCP Connection Status button, so the status line showed stale
data while packets were flowing. And on_tcp_packet_sent was reachable
only from the Sent arm, so show_metrics stayed false forever and
metrics_block early-returned every frame: the throughput indicator
added in oss-slu#109 has never once displayed.

Report Connected from the connect Ok arm, and Sent from try_send, which
is the single funnel all three packet-shape branches pass through.
SendRaw reports too, since a test packet is still a packet on the wire.

A failed write now propagates instead of being discarded: the fan-out
uses ? and the thread reports Disconnected and exits, reusing the
recovery path from oss-slu#179 that reaps the handle so Connect TCP works
again. Reporting each failed packet instead would write ~120 entries a
second into the event log and bury everything else in the panel.
SendError is left in place, documented as unconstructed.

Tests cover both halves: the status flips without a manual check, and a
sent packet makes the throughput block appear.
@Sanjana-Siddani
Sanjana-Siddani self-requested a review October 18, 2026 06:21

@Sanjana-Siddani Sanjana-Siddani left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

# Conflicts:
#	relay/src/message.rs
#	relay/src/state.rs
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

TCP thread never reports status, so the throughput indicator can never appear

2 participants