Repository navigation
fix(sites): keep serve rule exclusions on publish and warn when the edge never confirms the deploy - #256
fix(sites): keep serve rule exclusions on publish and warn when the edge never confirms the deploy#256jamie-at-bunny wants to merge 2 commits into
Conversation
…dge never confirms the deploy
🦋 Changeset detectedLatest commit: 1061f01 The changes in this PR will be included in the next version bump. This PR includes changesets to release 6 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
|
@codex review |
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. |
![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: a961972223
ℹ️ 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".
| return confirmed; | ||
| }, | ||
| ); | ||
| warnIfUnconfirmed(promoteConfirmed, deployId); |
There was a problem hiding this comment.
When the edge probe times out or another storage-origin rule keeps serving a different deploy, promoteConfirmed is false, but execution continues to emit live: true in JSON and, for reused content, “is now live”; deployments publish similarly emits published: true and “is now live.” Automation that consumes stdout therefore still treats the deployment as successfully live despite the new check proving otherwise, so the unconfirmed state needs to be reflected in the result and success messaging rather than only written as a stderr warning.
Useful? React with 👍 / 👎.
| const start = Date.now(); | ||
| const deadline = start + PROPAGATION_DEADLINE_MS; | ||
| let attempt = 0; | ||
| let confirmed = false; |
There was a problem hiding this comment.
When the first post-purge request reaches a node before the new rule has propagated, that request can cache the outgoing deploy for the zone's 30-day TTL. The newly documented behavior in packages/cli/README.md says this pull zone ignores query strings, so changing only __bunny_promote does not create a new cache key; every later attempt can therefore read the same stale header and leave confirmed false even after the rule has propagated, producing the new warning on a successful publish. The retries need a cache-bypass mechanism that the CDN actually honors, or a purge between attempts.
Useful? React with 👍 / 👎.
… path to bypass the cache
2 participants
Publishing a site now keeps paths users excluded from the serve rule (so a path like /api/* can be routed to another origin) and warns when the edge never reports the new deploy instead of claiming it is live.