dangernoodle-io / breadboard / 29954841211

96%

push

github

refactor!: migrate POST /api/reboot ingress off bb_json onto bb_data (B1-1148) (#1002)

Binds a "reboot" bb_data key (ts: BB_TYPE_U64, detail: BB_TYPE_STR) and
drives it through bb_data_apply(), same template as
bb_storage_http_routes.c's factory_reset_handler / bb_wifi_http_routes.c's
wifi_patch_handler. Deletes the hand-rolled bb_system_reboot_parse_body()
(components/bb_system/src/bb_system_reboot_parse.c) and its 17 host tests;
bb_json drops out of components/bb_system/CMakeLists.txt entirely.

- ts stays uint64_t on the wire struct (BB_TYPE_U64's populate path does an
8-byte memcpy); the route clamps it down to uint32_t by hand to (0,
UINT32_MAX], matching the deleted double-based clamp for every plain-integer
case (negative values wrap to a huge uint64_t and are excluded by the same
upper-bound check, no separate sign check needed).
- detail's max_len is sizeof(field) - 1 (not sizeof(field)), avoiding the
unterminated-buffer bug tracked as B1-1163 in factory_reset_apply's
"confirm" field.
- the User-Agent fallback merge and the on-device restart both stay in the
route, run AFTER bb_data_apply() returns, reading the same dst_scratch
buffer the route supplied -- the binding's apply() hook now also carries
one domain check (the ts divergence guard below), so it is no longer a
pure no-op.

ts validation (PR2 review, B1-1148 findings 1/2): "ts"'s raw JSON text
must be a clean base-10 integer -- ANY fraction or exponent ("1.9", "5e1",
"1.5e10", "1e300") is rejected with 400, because the "ts" field resolves
via bb_serialize_json_tok_get_i64() (strtoll(buf, NULL, 10), base-10 digits
only) while the JSON scanner accepts the full number grammar -- strtoll()
silently stops at the first character it can't consume, so a fraction or
exponent is otherwise mis-parsed rather than rejected. Detected via a
second field bound to the SAME "ts" wire key as BB_TYPE_F64 (strtod(),
which DOES honor the full grammar), compared against the BB_TYPE_U64 read
in reboot_apply... (continued)

7378 of 7968 branches covered (92.6%)

Branch coverage included in aggregate %.

12527 of 12689 relevant lines covered (98.72%)

2451.11 hits per line