dangernoodle-io / breadboard / 31065959540

97%

push

github

feat: remove last HTTP-specific fields from bb_data_http client (B1-1448) (#1237)

bb_data_http_client_t and bb_data_http_client_cfg_t drop fd/is_ws (and
the BB_DATA_HTTP_NO_FD sentinel they required) -- carrying them asserted
every consumer was a socket, which is exactly what a future MQTT/UDP
consumer is not. The espidf backend's shared send_fn/abort_fn seams
split into per-transport pairs (espidf_sse_send_fn/espidf_sse_abort_fn,
espidf_ws_send_fn/espidf_ws_abort_fn), each installed per-client at its
own connect site instead of branching on client->is_ws; the espidf
side tables (s_slots[]/s_ws_slots[]) already compute fd locally and
never needed to route it through cfg. bb_data_http_espidf_start() drops
its now-unnecessary module-wide send_fn/abort_fn install. The host
capture stub now records the client handle instead of fd/is_ws.

- host tests: strip .fd=/.is_ws= literals from ~90 acquire() call
  sites; multi-client identity assertions move from fd comparison to
  client-pointer comparison (the mechanical replacement bb_data_http_
  host_frame_at()'s out_fd/out_is_ws -> out_client requires)
- new test proves an MQTT-shaped acquire ({.subscribe_mask =
  BB_DATA_HTTP_SUBSCRIBE_EVENT, .send_fn, .send_ctx}) sets no
  socket-shaped field

Hardware validation (bench ESP32, 172.16.1.15, app-partition-only
flash, verify_flash digest matched, version banner dev-c776207 matched
this commit): clean boot, no panic, bb_data_http_init logged
max_clients=2 event_ring_capacity=16 max_poll_clients=2
max_push_clients=2 -- the shrunk pool sizing initialized fine. SSE
(/api/events) delivered 4 frames with correct "data: " framing. WS
(/ws/events) handshake 101 Switching Protocols, delivered 3 text
frames. The WS client reused the SSE client's fd after its curl timed
out, proving the split SSE abort seam tears its side-table entry down
cleanly on peer disappearance -- this is the epic's (B1-1123)
acceptance evidence that SSE and WS both work as fully independent,
non... (continued)

8518 of 9058 branches covered (94.04%)

Branch coverage included in aggregate %.

5 of 5 new or added lines in 2 files covered. (100.0%)

14249 of 14404 relevant lines covered (98.92%)

2601.96 hits per line