dangernoodle-io / breadboard / 29890147029

96%

push

github

refactor: fold bb_cache_routes into GET /api/diag/cache (B1-1121) (#991)

- deletes the bb_cache_routes component (CMakeLists/Kconfig/include, ESP-IDF + host platform files); the sole route it registered, GET /api/cache?key=<key>, moves into bb_diag_routes.c as GET /api/diag/cache?key=<key> -- same query-param shape (bb_dispatch_api is exact-match only, so a path-segment form would need bb_http_section wildcard dispatch and forfeit this route's hand-authored OpenAPI schema) and the same {ts_ms,data} envelope body from bb_cache_get_serialized(), verbatim
- gated under the existing CONFIG_BB_DIAG_ROUTES (bb_diag already privately requires bb_cache); the buffer-size Kconfig moves too, renamed BB_CACHE_ROUTES_BUF_BYTES -> BB_DIAG_CACHE_BUF_BYTES, same 768-byte default
- status mapper cache_route_status.{c,h} moves into bb_diag as bb_diag_cache_route_status.{c,h} (bb_diag_cache_route_map_status), always built unconditionally like its bb_diag_reset_decision.c/bb_diag_scrub.c siblings
- BB_ERR_UNSUPPORTED decision: maps to 501 (Not Implemented), not the prior 500 catch-all. #986 relaxed bb_cache_register() to accept cfg->serialize == NULL (rendered via bb_data instead) and left this mapping as a known wart, deliberately deferred here. A NULL-serialize key is a config/wiring state -- "this key will never render through this route" -- not a transient server fault, so folding it into the generic 500 (logged loud via bb_log_e) was operator-visible noise for a condition that isn't going to change on retry. 501 keeps it distinct from both 404 cases (key never registered / no snapshot yet) and the real 500 (serialize/buffer failure)
- no composition-root call sites needed updating: bb_cache_routes_init() had no REQUIRES-based or handwire caller anywhere in examples/floor or examples/smoke -- its only wiring was bbtool.toml's [capability.core] component list (updated) and its own // bbtool:init marker, picked up transitively by codegen; bb_diag_routes_init() is alre... (continued)

7460 of 8056 branches covered (92.6%)

Branch coverage included in aggregate %.

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

12620 of 12782 relevant lines covered (98.73%)

2422.18 hits per line