dangernoodle-io / breadboard / 30137884306

97%

push

github

fix: build SSE oneOf schema as a bounded fragment instead of nested json (#1063)

- build_operation()'s SSE branch now snprintf's the complete
  {"oneOf":[{"$ref":...},...]} fragment into a bounded stack buffer and
  splices it with bb_json_obj_set_raw, matching the existing static schema
  literal path
- avoids pushing nested oneOf array + $ref objects past depth 7, which
  would exceed bb_http_resp_json_obj's BB_JSON_OBJ_MAX_DEPTH=8 cap once
  PR4 ports this emitter onto that API
- buffer sized from BB_OPENAPI_SCHEMA_REGISTRY_CAP and the existing
  ref_val budget; overflow (many near-max-length component names at
  full registry cap) omits the content block rather than emit
  truncated JSON, exercised by a dedicated test
- update the OOM alloc-sequence tests/comments for the two allocs
  (content/media) that remain in the SSE branch, remove the three tests
  targeting the now-removed schema/one_of/ref bb_json_t allocations
- the fragment buffer (~1.9KB) is static, not stack: it's too large a
  fraction of the httpd worker's 6144-byte stack to carry as an
  automatic array in a frame under live dispatch (the exact budget
  B1-222 already blew once); safe because esp_http_server serializes
  all request handling in a single FreeRTOS task per httpd_start(),
  and bb_http.c starts exactly one
- check the ref_val snprintf return: a silently truncated component
  name would splice a wrong-but-well-formed $ref into the fragment;
  treat it the same as the outer overflow case (omit content), with
  a dedicated test
- collapse each overflow guard's `ret < 0 || (size_t)ret >= size` into a
  single unsigned comparison: snprintf can't return negative writing
  plain ASCII into these buffers, so the separate branch was dead and
  permanently missed by Coveralls; casting a hypothetical negative
  return to size_t already satisfies the >= check, so nothing is lost
- add a BB_OPENAPI_TESTING-gated test seam (bb_openapi_emit_internal.h,
  following the existing _for... (continued)

7742 of 8339 branches covered (92.84%)

Branch coverage included in aggregate %.

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

13227 of 13385 relevant lines covered (98.82%)

2500.79 hits per line