HYBIM-853 Bug fix for openapi upgrade

[shuningc]

Summary

• Fix scripts/patch_http_validation_error.py to match the 0.29.0 generator's from_dict shape (_LOOP_RE rewritten; _loop_replacement updated to emit list[ValidationError] | Unset style
  without Union)
• Regenerate src/splunk_ao/resources/ (1136 files) with openapi-python-client 0.29.0 — legitimate changes are Google-style docstrings, from future import annotations, response variable
  naming, and union reordering
• Restore metric_key_alias to openapi.yaml's ColumnInfo schema — the field was missing from the spec but is returned by the API and used throughout shared/column.py and experiment.py;
  0.29.0's stricter generation dropped it, breaking 5 tests

What was broken before this PR

Commit e121f41 (HYBIM-777) bumped openapi-python-client to 0.29.0 in pyproject.toml/poetry.lock but never regenerated the client. As a result:

1. The committed src/splunk_ao/resources/ was stale 0.26.x output
2. The patch script's regex no longer matched 0.29.0's from_dict shape — running the regen would silently drop the isinstance-guarded string-detail 422 fix and reintroduce a crash

Verification

• ./scripts/auto-generate-api-client.sh exits 0 ✅
• Second run produces zero diff (idempotent) ✅
• isinstance(_detail, list) guard confirmed present in http_validation_error.py ✅
• Generator warnings unchanged vs 0.26.x baseline (pre-existing spec issues only) ✅
• All imports resolve to splunk_ao.* (208 files confirmed) ✅
• Full test suite: 1817 passed, 11 skipped, 0 failures ✅

Test plan

• Run ./scripts/auto-generate-api-client.sh locally and confirm exit 0
• Run poetry install --all-extras && poetry run pytest and confirm no failures
• Grep src/splunk_ao/resources/models/http_validation_error.py for isinstance(_detail, list)

[fercor-cisco]

🤖 This review was generated by the Astra agent (claude-opus-4-8). It may contain mistakes.

Verdict: request_changes — Patch script and validation-error fix are correct and tested; but the manual metric_key_alias edit to the generated openapi.yaml is not durable and will be lost on the next spec import.

Follow-ups

Suggested follow-up work that could be tracked as Shortcut stories:

• scripts/patch_http_validation_error.py:54-64: The patch script itself has no unit test. Given its regex is tightly coupled to the generator's exact output (and already broke silently on the 0.26.x -> 0.29.0 bump), a small pytest that feeds a representative 0.29.0 from_dict snippet through patch() and asserts the isinstance-guarded result — plus an idempotency case — would catch future generator drift in CI rather than at regen time.

[fercor-cisco]

🟠 major (design): This metric_key_alias field is added by hand-editing openapi.yaml, but openapi.yaml is a generated artifact: scripts/import-openapi-yaml.sh regenerates it from the live server's openapi.json. Because the server spec does not include metric_key_alias on the ColumnInfo schema, the next run of import-openapi-yaml.sh will overwrite this file and silently drop the field again — reintroducing the exact 5 test failures this PR is fixing. This is the same "lost patch on regeneration" failure mode the PR is otherwise hardening against for the HTTPValidationError patch.

The durable location for local spec fixups is the yq patch block in scripts/import-openapi-yaml.sh (see the existing precedent there: StepType.enum += ["control"], with the comment "server omits this value from the spec but returns it" and "add the openapi.yaml patches here"). Please add the metric_key_alias injection to that yq expression (e.g. set .components.schemas.ColumnInfo.properties.metric_key_alias) so it survives a spec re-import. Note LogRecordsColumnInfo and the metric_* schemas already carry the field in the server spec, so only ColumnInfo needs the manual patch.

🤖 Generated by the Astra agent

[fercor-cisco]

🤖 This review was generated by the Astra agent (claude-opus-4-8). It may contain mistakes.

Verdict: approve — Patch-script fix is correct and tested, string-detail 422 handling is retained, and the reviewer's metric_key_alias concern is resolved via the main merge.

General Comments

• 🟡 minor (testing): The unit test's _UNPATCHED_0_29 sample is, per its own comment, "constructed from the regex in the patch script itself." That makes test_patch_rewrites_0_29_loop somewhat circular — it verifies the regex against a fixture derived from the same regex, not against real openapi-python-client 0.29.x generator output. If the actual generator ever emits a subtly different shape (blank-line placement, annotation wording), these tests would still pass while a real regen silently fails to re-apply the patch (exit 2), which is precisely the HYBIM-853 failure mode. The PR's manual verification (auto-generate-api-client.sh exit 0, sentinel present) covers this for now, but consider capturing a real generated snapshot as a fixture so the regression is caught in CI rather than by hand.

Follow-ups

Suggested follow-up work that could be tracked as Shortcut stories:

• scripts/import-openapi-yaml.sh:50-50: Consider adding a .components.schemas.ColumnInfo.properties.metric_key_alias injection to the yq patch block as a defensive measure, so the field survives even if a future server spec import drops it from ColumnInfo. This is only needed if the server spec's inclusion of the field is not guaranteed long-term.

[fercor-cisco]

Filed the two follow-up suggestions from the review as low-priority Jira tickets under HYBIM-697:

• HYBIM-904 — Capture a real openapi-python-client 0.29.x generator snapshot as a patch-script test fixture (addresses the circular test_patch_rewrites_0_29_loop fixture): https://splunk.atlassian.net/browse/HYBIM-904
• HYBIM-905 — Add defensive metric_key_alias injection to the yq patch block in import-openapi-yaml.sh: https://splunk.atlassian.net/browse/HYBIM-905