dangernoodle-io / breadboard / 29922070932

96%

push

github

refactor: delete bb_mdns_cache's legacy bb_json serializer (B1-1146b) (#998)

- deletes entry_serialize() (platform/espidf/bb_mdns_cache/bb_mdns_cache.c)
  -- the last remaining producer .serialize callback in the tree -- and
  drops the .serialize slot from its sole bb_cache_register() call site
  (cache_upsert()); no host-side registration existed, so there was only
  one site to fix (unlike display.info's two)
- VERIFIED before deleting, against the ticket's own caution not to trust
  a prior "COMPLETED" claim: PR #983 added bb_mdns_cache_entry_wire_desc/
  _fill (the replacement descriptor) but explicitly did NOT add a
  bb_data_bind() (its own header comment said so) -- confirmed by grep,
  not assumed
- deliberately does NOT add a bb_data_bind() here either, unlike diag.boot/
  update.available/health.display's own B1-1053/B1-1146a cutovers:
  bb_data_bind() binds exactly ONE fixed key to ONE descriptor, but
  bb_mdns_cache entries live at an open, runtime-determined set of keys
  ("<key_prefix><instance_name>" per peer) -- there is no single
  "the mdns_cache key" to bind. A future per-key reader (B1-1119) will need
  a different mechanism (most likely driving this same descriptor/fill
  directly against bb_cache_foreach()/bb_cache_get_raw() for a
  caller-supplied key), documented in bb_mdns_cache_wire_priv.h
- NO new REST route: GET /api/diag/cache?key=<mdns key> (the generic
  bb_cache debug dump) now 501s for any mdns_cache key instead of
  returning the real payload, identical to what already happened to
  diag.boot/update.available/health.display after their own cutovers --
  there was no dedicated route for an mdns_cache key before this PR either
- refresh finding (documented in bb_mdns_cache_wire_priv.h, VERIFIED
  against on_hello()'s and requery_work_fn()'s actual bodies, not assumed):
  unlike health.display (written exactly once), an mdns_cache entry is
  kept continuously warm by both event-driven hello() and periodic
  requery_wor... (continued)

7428 of 8018 branches covered (92.64%)

Branch coverage included in aggregate %.

12570 of 12732 relevant lines covered (98.73%)

2443.33 hits per line