ci: tolerate Cloudflare propagation lag (stale 200) in the stable smoke dev-floor check - #44
Merged
Conversation
…ke dev-floor check The post-deploy "Smoke test deployed stable manifests" step hard-failed the v0.3.0 release on `dev 0.2.0 is BELOW stable 0.3.0`, even though the deploy was correct (live stable AND dev manifests are 0.3.0 across all 4 targets, and the authoritative LOCAL pre-deploy "Floor dev channel to stable" gate already asserted dev>=stable). Root cause: the smoke's secondary dev>=stable check only tolerated a 404 as Cloudflare Pages propagation lag. But a stale edge returns HTTP 200 with the PREVIOUS (below-stable) dev version, and curl does not retry a 200 - so the check read the stale 0.2.0 manifest and failed the release. Same class as the earlier m10 404-retry fix, just the stale-200 variant. Fix: re-fetch the deployed dev manifest in a bounded loop until it is >= stable (rides out both 404 and stale-200 propagation); if it never catches up in the window, emit a ::warning:: instead of failing. The local pre-deploy floor gate is authoritative, so this eventual-consistency double-check must never fail the release on lag. dev-channel.yml's smoke has no cross-channel check and is unaffected. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_017GadVxaYAAY1Q5tRMNucrM
Contributor
Coverage
Gate: passed - no coverage regression (epsilon 0.1 pp). |
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
The v0.3.0
release.ymlrun failed itsSmoke test deployed stable manifestsstep withdev 0.2.0 is BELOW stable 0.3.0 for darwin/x86_64- but the release was correct: all 4 platform builds succeeded, and the live manifests serve stable AND dev = 0.3.0 across every target. Stable and dev users both correctly get 0.3.0.Root cause
The smoke's secondary
dev >= stablecheck (release.yml) only tolerates a 404 as Cloudflare Pages propagation lag. A stale edge instead returns HTTP 200 with the previous (below-stable) dev version, whichcurldoes not retry - so the check read the stale0.2.0manifest seconds after deploy and hard-failed. The authoritative local pre-deploy floor gate (floor-dev-channel.mjsassertFloored) had already enforceddev >= stable, so this post-deploy check is an eventual-consistency double-check that must never fail the release on lag. Same class as the earlierm10404-retry fix - this is the stale-200 variant.Fix
Re-fetch the deployed dev manifest in a bounded loop until it's
>= stable(rides out both 404 and stale-200 propagation); if it never catches up in the window, emit a::warning::instead of failing.dev-channel.yml's smoke has no cross-channel comparison and is unaffected.No app/runtime code changes; release-pipeline robustness only.
🤖 Generated with Claude Code