dangernoodle-io / breadboard / 30419712202 / 1

97%

main: 97%

push

github

fix!: report GET /api/diag/tasks stack_hwm in bytes, not FreeRTOS words (#1128)

tasks[].stack_hwm was straight from uxTaskGetSystemState()'s
usStackHighWaterMark (FreeRTOS words), while bb_task_registry's periodic
base scan (bb_task_registry_base_scan.c) converts the same quantity to
bytes for its own fields. Same concept, two units, no indication at either
surface -- anyone comparing this field against a Kconfig stack size (bytes)
was off by 4x on ESP32.

Extracts the shared conversion into bb_num_words_to_bytes() (components/
bb_num) rather than hand-rolling it a second time -- the CLAUDE.md
consolidation rule triggers on the second instance of a shared idiom.
bb_num is a pure/portable, host-testable component with zero platform
deps, so the helper takes plain integers (words, word_size) and stays
FreeRTOS-agnostic; both call sites pass sizeof(StackType_t) at their own
ESP-IDF-aware boundary. This also fixes an incidental-correctness gap in
the pre-existing base_scan.c copy, which multiplied at uint32_t width
(safe only because real stacks never approach 2^30 words) -- the shared
helper widens to int64_t before multiplying, correct by construction.
bb_diag_http and bb_task_registry both gain a PRIV_REQUIRES bb_num edge
(internal .c use only, no public header exposes it).

Field name is unchanged (stack_hwm, not renamed) per explicit decision --
bytes is the useful unit for comparing against Kconfig budgets with no
mental math.

The host regression test for the width property guards against a
bit-for-bit uint32_t-width reintroduction of the original bug; it cannot
catch a subtler cast-removal that still widens correctly on a 64-bit-size_t
host -- that narrower class is unreachable from a host test (see the
test's own comment for the full disclaimer, including the ESP32-only
32-bit-size_t truncation it also can't reproduce).

BREAKING: this is a wire-format change for external consumers of GET
/api/diag/tasks. Old clients silently read stack_hwm as ~... (continued)

7896 of 8500 branches covered (92.89%)

Branch coverage included in aggregate %.

13427 of 13582 relevant lines covered (98.86%)

2616.97 hits per line