dangernoodle-io / breadboard / 31237122345

97%

push

github

refactor: give bb_log_e/w/i/d/v a structured call-site producer (B1-1443 PR-1) (#1253)

bb_log_emit() replaces ESP_LOGx as the producer for our own log calls,
stamping ts and building level/tag/msg at the call site instead of
reconstructing them by re-parsing the console-formatted text downstream.
Fans out directly to every existing consumer (console writer queue,
bb_diag panic tap, optional UDP mirror, bb_log_event forwarder) via a
two-layer gate (compile-time LOG_LOCAL_LEVEL, runtime per-tag lookup)
that mirrors ESP-IDF's own internal cost, so below-threshold calls still
dead-strip. Foreign/vendored ESP_LOGx output is untouched -- it still
flows through the vprintf hook and bb_log_line_parse exactly as before.
The /api/events?topic=log wire shape is unchanged.

Review follow-ups addressed (round 1):
- Extracted bb_log_emit()'s console-line and bb_log_event_msg_t
  construction into pure, portable functions (bb_log_emit_build_line(),
  bb_log_emit_build_event_msg(), components/bb_log/src/
  bb_log_emit_build.c) with host tests covering tag/msg truncation
  boundaries and the NULL-tag/NULL-msg paths. Full injection testing of
  the four-way queue fan-out itself still needs a seam that doesn't
  exist yet -- filed as a follow-up rather than attempted here.
- Documented, at the bb_diag tap call site in bb_log_emit(), why calling
  the tap unconditionally is safe regardless of composition-root init
  order: the sole tap setter (bb_diag_panic_init()) already calls
  bb_log_stream_init() itself, idempotently, immediately before
  installing the tap.
- Reordered bb_log_event_msg_t's fields (8-byte-aligned members first)
  to remove dead alignment padding, and pinned the struct's size with
  a _Static_assert in bb_log_internal.h.
- Corrected the heap-cost accounting: CONFIG_BB_LOG_EVENT_QUEUE_LEN
  defaults to 24 slots without PSRAM but 48 with it, so the worst-case
  heap delta over the old (smaller) per-slot struct is roughly double
  the previously-quoted... (continued)

8574 of 9114 branches covered (94.08%)

Branch coverage included in aggregate %.

37 of 37 new or added lines in 3 files covered. (100.0%)

14309 of 14464 relevant lines covered (98.93%)

2601.87 hits per line