dangernoodle-io / breadboard / 26133941011

100%

push

github

fix(bb_event_routes): event-driven SSE wake + TCP_NODELAY + faster peer-disconnect cleanup (#277)

* fix(bb_event_routes): event-driven SSE wake + TCP_NODELAY + faster peer-disconnect cleanup

The per-client SSE writer in bb_event_routes previously polled with
vTaskDelay(200ms), adding up to 200ms latency to every event delivery,
and only noticed peer disconnect when send_chunk failed (up to one
heartbeat interval) or SO_RCVTIMEO fired (30s). With Nagle on the
socket, small SSE frames could be held another 40-200ms.

The combined effect made TA-376-style scenarios worse on tdongle-s3:
during page navigation, the old per-client task could linger long
enough for a reconnecting browser to acquire a second slot, doubling
load on the lwip TCPIP_CORE lock and amplifying httpd_thread starvation.

This change:

- adds a new per-client port_event handle (binary semaphore on ESP-IDF,
  no-op sentinel on host); capture_cb signals it after enqueueing so
  the writer task wakes immediately instead of polling
- sets TCP_NODELAY on the SSE socket so small frames flush without
  Nagle holding them for an ack timer
- adopts the MSG_PEEK | MSG_DONTWAIT peer-disconnect probe pattern
  from bb_log_routes so the writer notices browser FIN/RST within one
  loop iteration and frees the client slot promptly
- drains the full queue per wake (not just one frame) so a burst of
  events doesn't wait for N successive wakes to flush

bb_event_routes_port_notify stays as a no-op for back-compat. The
ESP-IDF impl now also exposes port_event_{create,destroy,signal,wait};
host platform supplies safe no-op stubs since unit tests drive drain
explicitly. New accessor bb_event_routes_client_event() lets platform
code reach the per-client event handle without touching the opaque
client struct.

Refs B1-217, B1-219, B1-220. The shared SSE-writer pattern between
bb_log_routes and this file is tracked separately as B1-221.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

* test(bb_ev... (continued)

1000 of 1000 branches covered (100.0%)

Branch coverage included in aggregate %.

11 of 11 new or added lines in 1 file covered. (100.0%)

1795 of 1795 relevant lines covered (100.0%)

1000.19 hits per line