dangernoodle-io / breadboard / 30181065481

97%

push

github

fix: migrate bb_lifecycle/bb_lifecycle_async onto bb_lock_once_ensure() (#1088)

Each site guarded a fallible bb_lock_init() with the plain, non-fallible
bb_once_run(), discarding the failure -- bb_once_run() latches DONE
unconditionally, so a transient boot-OOM left a zero-inited bb_lock_t
and permanently bricked every future caller of the service-registry
authority underpinning the composition root.

- bb_lifecycle.c: ensure_lock() now returns bb_err_t via
  bb_lock_once_ensure(); every call site (autoinit, register, find, name,
  start, stop, pause_assert, pause_clear, is_paused, state,
  inhibit_words, reason_name, priv_observe_slot, reset_for_test)
  propagates or folds the failure into its existing return shape --
  bb_err_t-returning functions propagate the real error; bool/const
  char*/size_t/state-returning functions fold it into their existing
  "invalid handle" default (false/""/0/STOPPED), documented as
  indistinguishable from that case rather than conflated with the
  NULL-argument caller-bug convention
- bb_lifecycle_async.c: ensure_async_lock() now returns bb_err_t the same
  way; removed the false "the lock itself has no transient-failure retry
  requirement, safe to latch forever" comment -- bb_lock_init() failure
  is exactly the transient condition bb_lock_once_ensure() exists to
  retry, not latch
- updated bb_lifecycle.h/bb_lifecycle_priv.h doc comments for the new
  possible lock-unavailable error/fallback on each affected function
- swept every caller of every widened function (bb_mdns.c, bb_mqtt_
  client_espidf.c, examples/floor/main/floor_app.c): all already handle a
  bb_lifecycle_find()/observe_async() BB_ERR_NOT_FOUND-or-other failure
  identically via an existing else/!=BB_OK branch, so a lock-unavailable
  failure surfaces through the same already-correct path -- no caller
  invariant broken, no fix needed
- the genuine bb_lock_init() failure branch is not host-reproducible (no
  fault injection); each new branch is LC... (continued)

7770 of 8375 branches covered (92.78%)

Branch coverage included in aggregate %.

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

13221 of 13378 relevant lines covered (98.83%)

2658.32 hits per line