dangernoodle-io / breadboard / 30183047735

97%

push

github

feat(bb_settings): add durable provisioned flag getter + connect-time set seam (#1092)

B1-807, corrected design: the canonical "is this device provisioned" bit is
the durable NVS "bb_cfg"/"provisioned" key bb_settings already wrote (via
bb_settings_creds_boot_init's heal branch) but never exposed a public getter
for -- NOT the RTC mirror's own copy, which is volatile and degenerate
(bb_settings_wifi_rtc_mirror_write hardcodes provisioned=1 on every mirror
write regardless of an actual validated connect).

Adds bb_settings_wifi_provisioned_get() (fail-closed on any backend error or
unset key) and a bb_core callback-slot seam
(bb_settings_wifi_set_provisioned_cb) that fires exactly once, on the
false->true transition, at the first validated WiFi connect. One writer,
bb_settings_wifi_provisioned_mark_connected(), covers both creds paths: the
reconfigure-promote path (bb_settings_wifi_pending_promote calls it right
after its own atomic ssid/pass/try commit) and the captive-portal
direct-commit path (bb_wifi's IP_EVENT_STA_GOT_IP handler calls it directly
when no promote ran on that connect). No public setter is exposed -- this is
a read+notify seam only.

Deviation from the ticket's literal requirement 3(c): the flag is NOT staged
as a 4th key in bb_settings_wifi_pending_promote's atomic bb_config_staged
session. BB_STORAGE_TXN_MAX_KEYS defaults to 3, and the ssid/pass/try triple
already uses every slot -- a 4th key there would fail loudly and atomically
(bb_storage_txn_slot_stage bounds-checks and returns BB_ERR_NO_SPACE,
poisoning the txn so every backend's commit refuses to write anything at
all), not silently corrupt anything. The reason to avoid it is that
BB_STORAGE_TXN_MAX_KEYS is a global cap: widening it to fit a 4th key here
would grow every unrelated bb_storage_txn_t consumer's static footprint
repo-wide, well outside this ticket's flag-and-seam scope (B1-1235 tracks
making txn capacity caller-sized instead). Promote instead calls the flag
wri... (continued)

7784 of 8389 branches covered (92.79%)

Branch coverage included in aggregate %.

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

13235 of 13392 relevant lines covered (98.83%)

2619.63 hits per line