dangernoodle-io / breadboard / 29894373581

96%

push

github

refactor: drop display.info's legacy bb_json serializer (B1-1146a, last piece of B1-1053) (#997)

- deletes bb_display_serialize() (components/display/bb_display/src/
  bb_display_info_event_common.c, whole file) -- the legacy bb_json
  bb_cache serializer for the "health.display" topic -- and drops the
  .serialize slot from both bb_cache_register() call sites (platform/
  espidf/bb_display/bb_display_info.c, platform/host/bb_display/
  bb_display_info.c)
- adds bb_display_info_bind() (bb_display_info_wire.c, mirrors
  bb_diag_boot_bind()/bb_ota_check_bind()'s composition-time self-bind
  pattern) against the health.display bb_serialize_desc_t added by
  B1-1045 PR-2 (bb_display_info_wire_desc); bb_display_register_info()
  now calls it on both platforms right after bb_cache_register()
  succeeds, non-fatal on failure (logged)
- NO new REST surface: health.display's REST exposure is already
  designated to go through bb_system's diag endpoint under the name
  system.display (B1-1150, a separate ticket rehoming the topic) --
  this PR does not add a competing /api/display/info route. The bind
  above exists purely so that future bb_system-side reader can resolve
  the key via bb_data_render() once it lands
- net effect: GET /api/diag/cache?key=health.display (the generic
  bb_cache debug dump, folded in from the deleted bb_cache_routes
  component, B1-1121) now 501s for this key instead of returning the
  real payload -- identical to what already happened to key=diag.boot
  and key=update.available after their own B1-1053 cutovers; there is
  no other REST regression, since no dedicated route existed for this
  key before this PR either
- preserved finding, moved onto bb_display_info_gather()'s doc comment
  (bb_display_info_wire.h) rather than deleted along with the route
  code that would have needed it: health.display's bb_cache entry is
  written EXACTLY ONCE, at bb_display_info_register_init() -- VERIFIED
  against bb_display_info_gather()'s actu... (continued)

7428 of 8018 branches covered (92.64%)

Branch coverage included in aggregate %.

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

12570 of 12732 relevant lines covered (98.73%)

2442.59 hits per line