fix(admin): accept the GA server identity and key the version baseline on release line - #224
fix(admin): accept the GA server identity and key the version baseline on release line#224mikemcdougall wants to merge 2 commits into
Conversation
Issue #219 reported that the Admin SDK rejected the exact trunk server identity 1.0.0+32809f114c36c951b00beb5fe07a3c7082867909. The baseline was corrected on trunk by #220; this pins that behaviour so it cannot silently regress, and adds the version-policy coverage the corrected dual baseline needs. Expected values are computed from the documented policy (GA SemVer supported from 1.0.0, pre-GA CalVer from 2026.3.0), not captured from evaluator output: each case asserts the exact supported flag, the exact reason list, the empty warning list, and the parsed control-plane major, base path and release channel echoed back from the capabilities response. The reported identity is driven end to end through both the sync and async admin clients over a mock transport that asserts the request lands on GET /api/v1/admin/capabilities, with independent rejection cases for a mismatched API major, base path and release channel.
…hape The dual baseline added with the #219 correction picked between the GA SemVer minimum (1.0.0) and the retained pre-GA CalVer cutoff (2026.3.0) by matching the server version against a fixed CalVer shape: four-digit year, then two one-or-two-digit components, then optional pre-release or build metadata. Any pre-GA identity outside that exact shape fell through to the GA baseline, where its year-valued major compared greater than 1 and the build was reported supported. A four-component build such as 2026.2.28.1 or 2026.2.0.99+<sha> is below the 2026.3.0 cutoff but was accepted, which is the same class of defect as #219 in the opposite direction: the cutoff #220 set out to preserve did not hold for those identities. Detection now keys on the leading version component. A leading component of 2000 or greater is a calendar year and selects the CalVer cutoff, so component count, separator and build metadata no longer decide which baseline applies. The compatibility matrix gains the cutoff boundary (2026.3.0, supported) and both four-component identities (unsupported), so the shared cross-SDK contract fixture and scripts/compatibility_gate.py enforce the rule alongside the Python tests.
GitHub Actions
Failure
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
GitHub Actions
Failure
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 83f9fb89d1
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
Gate status at head (
|
1 participant
Issue
Closes #219
Summary
Issue #219 reported that
HonuaAdminClient.check_compatibility()rejected the exact trunk server identity1.0.0+32809f114c36c951b00beb5fe07a3c7082867909with "Server version … is below required '2026.3.0'", because the Admin SDK hard-coded a CalVer-onlyMINIMUM_SUPPORTED_SERVER_VERSION.The baseline itself was already corrected on trunk by #220, which introduced a dual baseline: GA SemVer from
1.0.0, pre-GA CalVer retained at2026.3.0. This PR pins that behaviour as a regression, and fixes a hole in the dispatch between the two baselines that the correction left open.Changes Made
1. Regression evidence for the reported identity (
tests/admin/test_compatibility.py)The exact reported identity is driven end to end through both the sync and async admin clients over a mock transport that asserts the request lands on
GET /api/v1/admin/capabilities, with independent rejection cases for a mismatched control-plane API major, base path, and release channel.Expected values are computed from the documented policy, not captured from evaluator output. Each case asserts the exact
supportedflag, the exactreasonslist, an emptywarningslist, and the parsedserver_version/release_channel/control_plane_api.major/control_plane_api.base_pathechoed back from the capabilities response.2. Baseline dispatch keyed on release line, not string shape (
packages/honua-admin/honua_admin/_models.py)_is_calver()chose between the two baselines by matching the version against a fixed CalVer shape — four-digit year, then two one-or-two-digit components, then optional pre-release/build metadata. Any pre-GA identity outside that exact shape fell through to the GA baseline, where its year-valued major compared greater than1and the build was reported supported:2026.2.28.12026.3.02026.2.0.99+<sha>2026.3.0This is the same class of defect as #219 in the opposite direction: the cutoff #220 set out to preserve did not hold for those identities. Detection now keys on the leading version component —
2000or greater is a calendar year and selects the CalVer cutoff — so component count, separator, and build metadata no longer decide which baseline applies.3. Shared contract fixture (
compatibility/server-matrix.json) gains the cutoff boundary (2026.3.0, supported) and both four-component identities (unsupported), soscripts/compatibility_gate.pyenforces the rule alongside the Python tests. Docs updated indocs/compatibility.mdandINSTALL.md.Breaking Changes
None for GA identities. Pre-GA CalVer builds below
2026.3.0that were previously accepted through the shape hole are now correctly rejected — that is the cutoff working as documented.Gate Impact
Testing
Mutation-verified — the tests fail against the pre-fix code and pass against it:
MINIMUM_SUPPORTED_SERVER_VERSIONto"2026.3.0"(the [Bug Hunt] Admin compatibility baseline rejects exact trunk 1.0.0 server #219 defect) fails 12 tests, including both the sync and async variants — confirming the async cases genuinely execute rather than passing vacuously as un-awaited coroutines._is_calver()fails exactly the two four-component cases.Local runs at head:
pytest tests/→ 1722 passed, 18 skippedpython scripts/compatibility_gate.py→ passedruff check .→ passedmypy(strict) → no issues in 70 source filespython scripts/check_docs_command_policy.py→ passedpython scripts/gen_sync.py --check→ sync/async twins in lockstepDisposition
1.0.0+<sha>GA identity, pinned by sync and async regression coverage plus the shared matrix fixture, and the CalVer/SemVer baseline dispatch no longer depends on version string shape.Note on scope, carried forward from the trunk documentation: published
honua-admin0.1.8 predates the GA baseline correction and still rejects that identity. Source-level compatibility does not update an installed wheel — the corrected baseline must ship in the admin package selected by the release train. The fixtures here are deterministic transport tests; they protect the runtime policy but do not certify a deployed release candidate.