dangernoodle-io / breadboard / 30664027195

97%

push

github

refactor: relocate bb_system/bb_health/bb_openapi route markers to manifest (#1163)

B1-1315 (epic B1-1314): scripts/bbtool/commands/wire.py's `--consumer-manifest`
composition lets a component's `// bbtool:init` markers force its entire
route surface onto every consumer that composes it for unrelated reasons
(B1-1279) -- composing bb_system for the reboot-reason SSOT also registered
POST /api/reboot, undeclinable. This moves the first batch of
route-registering (`server=true`) markers out of component headers and into
examples/smoke/main/bb_wire.h as manifest-only entries, each carrying
`component=<name>` to pull that component's REQUIRES/PRIV_REQUIRES closure --
mirrors the existing bb_wifi_prov_autoinit precedent in the same file.

Moved (doc comments kept, only the marker line removed):
- bb_system_routes_init (components/bb_system/include/bb_system_routes.h)
- bb_health_init (components/bb_health/include/bb_health.h)
- bb_openapi_init (components/bb_openapi/include/bb_openapi.h)

Byte-identity does NOT hold for this relocation, and that's expected, not a
defect -- recorded here so the next batch's author doesn't rediscover it:

- codegen merges `entries = collect_entries(...) + manifest_entries` (see
  wire.py's `run()`) BEFORE wire_graph.topo_sort, and topo_sort's tie-break
  is `(order or +inf, global_parse_index)`. Manifest entries are therefore
  always appended after every component-header entry for tie-break purposes,
  regardless of the marker's original position in the composition-order
  walk. An explicit `order=` doesn't help either: any finite order sorts
  ahead of every `order=None` (+inf) entry, which would hoist these calls to
  the very front of the regular tier -- a different, still non-identical
  order, not a match. Reproducing the exact original interleaving would
  require adding `order=` to the surrounding entries in unrelated components
  (bb_ota_validator, bb_diag_http, bb_mdns, bb_wifi_http, etc.) -- out of
  scope for a ... (continued)

8092 of 8668 branches covered (93.35%)

Branch coverage included in aggregate %.

13719 of 13874 relevant lines covered (98.88%)

2583.57 hits per line