fix(cli): don't assume newest deployment is live in promote resolution#124
Conversation
resolveCurrentLiveDeploymentId fell back to deployments[0] (the newest) when no authoritative live signal was available (app.liveDeploymentId, provider live flag, or local known-live state). During promote this made a freshly created candidate look "already live", so the endpoint rebind was skipped and an app whose live pointer had been cleared never got re-bound — leaving it unreachable across repeated deploys. Return null instead: unknown live deployment means "not already live", so the promote proceeds and rebinds the endpoint. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
|
Warning Review limit reachedYou’ve reached a temporary PR review limit under our Fair Usage Limits Policy. Next review available in: 20 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro Run ID: 📒 Files selected for processing (1)
WalkthroughThe app controller no longer assumes the newest deployment is live when no authoritative live signal exists; it returns 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
✨ Simplify code
Comment |
Comply with the house rule that a comment needing more than one line belongs in the API doc. The null-means-unknown contract now documents resolveCurrentLiveDeploymentId itself. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
|
@CodeRabbit approve |
|
@coderabbitai approve |
|
@coderabbitai review |
✅ Action performedComments resolved and changes approved. |
✅ Action performedComments resolved and changes approved. |
✅ Action performedReview finished.
|
Why
resolveCurrentLiveDeploymentIdfell back todeployments[0](the newest deployment) when no authoritative live signal was available (app.liveDeploymentId, the providerliveflag, or local known-live state):During
app promote, this made a freshly created candidate look like it was already live, so promote emitted "The selected deployment is already live for this app." and skipped the endpoint rebind. An app whose live pointer had been cleared (e.g. its live deployment was stopped) therefore never got re-bound — every subsequent deploy hit the same false "already live" and left the app unreachable.This was the second half of a production incident on 2026-07-20: after the live deployments of build-runner/github-webhook were stopped (clearing
latestDeploymentId), each CI redeploy's promote step read the null pointer, hit this fallback, and skipped the rebind — turning a transient stop into a ~1h outage.What
Return
nullinstead of guessing the newest. "Unknown live deployment" now means not already-live, so promote proceeds and rebinds the endpoint.Tests
promote rebinds instead of assuming the newest deployment is live when there is no authoritative live signal.app-controllersuite green.🤖 Generated with Claude Code