Decouple the live latest-pointer loader test from which release is current#392
Merged
Merged
Conversation
…rrent Main has been red since #389: the Build J re-certification moved the Hub's latest.json from Build I to Build J, and test_existing_certified_release_metadata_resolves_through_latest_pointer pinned the Build I release id and artifact digest. The loader is follow-the-pointer by design (there is no API to request a specific release id), so this was a stale pin of live remote state, not a resolution bug — and any pin here reds main again on the next re-cert. - Rewrite the live test as release-agnostic structural checks: the currently published chain must resolve coherently (id prefix, repo, filename, revision pinned to the release id, sha shape, engine certification) without asserting which release is current. - Pin exact release-metadata equalities against the FakeHubDownload fixture instead, where the suite controls the pointer. - Add a fixture test for the re-certification semantics themselves: publishing a successor moves the pointer and resolution follows. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Assert populace-{country}-{spec.year}-* rather than just the country
prefix, and note in the docstring that release-identity pinning belongs
to policyengine.py's certification fixtures (updated atomically with
each certification PR), not to this repo's live tests.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
MaxGhenis
added a commit
that referenced
this pull request
Jul 12, 2026
Integrates the SNAP state surface (#256 #371 #376), the PUMA ladder (#394), the loader-test decouple (#392), and --no-latest (#397) with the campaign's 93 restored input families. Six builder conflict hunks + the us_runtime export merges resolved keeping BOTH lineages: main's snap_state_take_up stage/diagnostics/telemetry sequenced alongside the campaign's other_health_insurance and ssi_take_up stages. Full populace-build suite passes on the merged tree (exit 0, 1 cred skip). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What happened
Main's
Testsworkflow has been red on push since #389 merged (64a373e):test_existing_certified_release_metadata_resolves_through_latest_pointer[us-...buildi...]failed in bothtest (3.13)andwheels(fail-fast cancelled 3.14). #389 published the Build J release, which movedlatest.jsoninpolicyengine/populace-usfrom Build I to Build J; the test pinned the Build I release id and artifact sha256.Diagnosis: stale pin, not a loader bug
The loader is follow-the-pointer by design.
resolve()takes(country, year, variant), and_resolve_certified_release()always resolves the mutablelatest.jsonand reads the manifest at that release's immutable tag — there is no API surface for requesting a specific (superseded) release id, so the test could not have been asserting an immutable-resolution invariant. It was asserting a snapshot of live remote state, which every re-certification invalidates without any commit in this repo. Bumping the pin to Build J would just red main again at Build K.Fix
test_live_latest_pointer_resolves_to_a_coherent_certified_release): now release-agnostic. It proves the currently published chain resolves coherently —populace-{country}-id prefix, repo/filename match the registry spec, manifest revision pinned to its own release id, well-formed sha256, engine certification present — without asserting which release is current. It still catches genuinely broken publications; it no longer breaks on routine re-certs.FakeHubDownloadfixture test (test_resolve_certified_release_returns_pointer_pinned_metadata), where the suite controls the pointer.test_recertification_advances_the_pointer_and_resolution_follows): publishing a successor release moves the pointer and resolution follows — the exact event that redded main, now covered hermetically.The Build I ids/shas pinned nowhere else in the repo (grepped). Unrelated to #256/#371 (SNAP targets); those are untouched.
Verification
uv run pytest packages/populace-data/tests— all pass locally (2 environmental skips:policyengine-usnot installed in this venv;populace-uk-privateneeds the HF credential CI has). The live US case ran against the real Hub and resolved Build J green.ruff format+ruff checkclean.🤖 Generated with Claude Code