dangernoodle-io / breadboard / 29965562725

96%

push

github

refactor: migrate DELETE /api/diag/storage request parsing off bb_json (B1-1147) (#1007)

- dual-key technique: binds "namespace" TWICE in the same bb_serialize
  descriptor, once as BB_TYPE_STR and once as BB_TYPE_ARR of BB_TYPE_STR;
  each getter type-checks its own wire token and fails closed, so exactly
  one form is ever populated per request -- no union/oneOf type needed,
  no bb_serialize core changes (mirrors bb_system_routes.c's s_reboot_fields
  dual-key precedent for "ts")
- storage_delete_apply() (the "storage_delete" bb_data binding's apply hook)
  does structural validation only (confirm, wipe_wifi guard, namespace
  presence/shape/cap, key+array ambiguity, oversize-reject on
  backend/key/namespace); the actual erase + response building stays in
  storage_delete_handler() after bb_data_apply() returns, since the 200
  response needs a per-request dynamic list of erased namespaces that
  apply()'s bb_err_t-only return can't carry back out (same posture as
  bb_system_routes.c's reboot_handler)
- drives bb_data_apply() under BB_DATA_APPLY_PATCH (not POST) specifically
  so storage_delete_gather() runs before populate and can pre-wire the
  array field's backing storage -- BB_DATA_APPLY_POST's zero-fill has no
  caller hook point and would wipe any pre-wiring done beforehand
- status-code matrix preserved: confirm/wipe_wifi guard -> 412; namespace
  absent/wrong-type/oversized, array-over-cap, key+array combo, oversized
  backend/key -> 400; unsupported backend op -> 501; other erase failure
  -> 500; success -> 200 (unchanged wire response)
- documents one intentional behavior change (review finding): an explicit
  empty-string "namespace" is now rejected 400 by the presence check
  instead of reaching bb_storage_erase_namespace() -- on the real
  bb_storage_nvs backend that call's own nvs_open("", ...) returns
  ESP_ERR_NVS_INVALID_NAME (namespace names "shouldn't be empty" per
  nvs_open()'s own contract), which the pre-migration handle... (continued)

7386 of 7976 branches covered (92.6%)

Branch coverage included in aggregate %.

12530 of 12692 relevant lines covered (98.72%)

2497.9 hits per line