Relationships
#2660 GCP codegen: a same-surface merge that fails to parse drops the whole preferred document silently
Opened by stack72 · 9/28/2026
Follow-up from swamp-club #2629.
generateGcpModels (codegen/gcp/pipeline.ts) merges same-surface additional versions (compute 2026-09-01 and stable into v1) into the preferred raw discovery document before dereferencing and parsing. If a future additional version merges in something that makes dereferenceGcpDiscoveryDocument or parseGcpDiscoveryDocument throw, the error is only pushed to the errors list and every resource of that API is lost, not just the merged additions. generate:gcp still exits successfully, so the nightly regeneration would not fail and the service models would silently stop updating.
Suggested hardening: when the merged document fails to parse, fall back to parsing the unmerged preferred document plus the additional versions through the per-resource dedup path, record the merge failure as an error, and consider making generate:gcp exit non-zero when errors are reported. Not reachable with the current compute documents; raised as a medium finding by the verify-reviews adversarial review.
Closed
No activity in this phase yet.
stack72 commented 9/29/2026, 11:23:34 AM
Closed out: fixed in https://git.swamp-club.com/swamp-club/swamp-extensions/pulls/349 (merged and published, tracked under the #2662 lifecycle). If a merged GCP document fails to parse, generation now falls back to the unmerged preferred document, and merged versions contribute only resources it lacks. Per-resource parse failures that were silently swallowed are now reported. When anything in a service fails (schema file, document or resource), its existing models are kept at their last good version instead of being pruned. generate:gcp exits 2 after writing what did generate, and the nightly regenerate-models workflow continues past a failed provider, discards a crashed provider's partial output, and fails the run at the end.
Sign in to post a ripple.