fix(server): invalidate CloudFront for build routes on new build - #381
yuvrajjsingh0 wants to merge 1 commit into
Conversation
|
Warning Review limit reached
Next review available in: 58 minutes Limit details: You’ve used all 1 included review currently available under your plan. You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. 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: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
8f58764 to
813648c
Compare
813648c to
d78346d
Compare
Problem
When a build produces a new zip/aar and writes a new version row, nothing purges the CloudFront cache for the
/buildroutes.The only
invalidate_cfcall sites are inrelease.rs(create / ramp / conclude), and they all invalidate/release/{org}/{app}*. That glob never matches/build/{org}/{app}— the build routes are a separate scope (main.rs).Meanwhile
serve_versionexplicitly sets a day-long edge TTL:and the
zip/aarbodies change with every version. So clients keep getting the previous version for up to 24h after a new one is ready.Worst case is the background build path (
x-force: false): the request returns the old version immediately and builds the new one in atokio::spawn. That stale response is what gets cached at the edge, and the build that follows has no way to clear it.Fix
Add an
invalidate_build_cf(state, org, app)helper inbuild.rsthat purges/build/{org}/{app}*, and call it at the end ofbuild().It runs after the artifacts are uploaded (Step 2), the row is marked
READY(Step 3), andbuild.last_created_build_ridis updated (Step 5) — invalidating any earlier would let a request racing in behind the purge resolve the old release id and re-cache the stale version.Failures are logged rather than propagated, matching the existing release-side call sites: the build itself has already succeeded by that point.
Notes
CLOUDFRONT_DISTRIBUTION_IDandrelease::utils::invalidate_cf, so no docs change is needed./build/*includes thex-dimensionheader in the cache key. The response varies by dimension, so if it isn't keyed on that, different cohorts share one cached entry — a separate issue this PR doesn't address.Testing
cargo checkandcargo clippypass clean onairborne_server.