Repository navigation
fix: key the runtime's repo pull on config_updated_on instead of updated_on - #10049
Open
nishantmonu51 wants to merge 2 commits into
Open
nishantmonu51 wants to merge 2 commits into
nishantmonu51 wants to merge 2 commits into
Conversation
…ts status unchanged Since #9653 the ValidateDeploymentsWorker schedules ReconcileDeployment for every prod deployment twice an hour. For a running deployment the job always called UpdateDeploymentStatus(Running, ""), which sets updated_on = now() even when nothing changed. The runtime's configReloader uses updated_on as its "deployment changed" signal, so every reload forced a repo pull and a full re-parse of the project (or a controller restart for archive-backed projects), cancelling in-flight reconciles. The job now re-fetches the deployment and only writes the status when it actually differs. The re-fetch matters because UpdateDeploymentInner may have moved the status to updating in the DB without updating the job's copy. Side effect: the orphaned prod deployment teardown in ValidateDeploymentsWorker (updated_on older than 3h) can fire again, as it did before v0.89.
k-anshul
requested changes
Oct 21, 2026
k-anshul
left a comment
Member
There was a problem hiding this comment.
This doesn't seem safe on a high level.
A lot of validation/garbage collection in admin depends on updated_on so bumping it on reconcile seems correct.
May be we should revisit the approach commented here :
rill/runtime/config_reloader.go
Lines 28 to 32 in de14a79
…d of `updated_on` Keeps the reconcile heartbeat; the runtime now keys repo pulls on desired_status_updated_on, which status writes don't touch, and only records it after a successful reload. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
updated_on when a reconcile leaves its status unchangedconfig_updated_on instead of updated_on
This branch has not been deployed
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
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.
ValidateDeploymentsWorkerreconciles every prod deployment twice an hour, and each reconcile bumpsupdated_onthroughUpdateDeploymentStatus.configReloadertreatedupdated_onas its "deployment changed" signal, so every hourly reload forced a repo pull and a full re-parse (a controller restart for archive-backed projects), cancelling in-flight model reconciles. Status changes from slot changes and resumes had the same effect.GetDeploymentConfigResponsenow hasconfig_updated_on, set fromdesired_status_updated_on. Every change that must reach the runtime (branch, project, variable and desired-status changes) bumps that column; status writes don't.configReloadercompares it instead ofupdated_on.configReloaderonly recordsconfig_updated_ononce the pull, parser trigger andEditInstancesucceed, so a failed reload is retried on the next reload.updated_on. The orphaned prod deployment check inValidateDeploymentsWorkerrelies on that to keep non-primary prod deployments alive.TestRuntimeDeploymentsasserts that a second no-op reconcile doesn't re-parse the project even though the first one bumpedupdated_on, and that a reconcile after a--prod-slotschange leaves the deploymentRunning.Checklist:
Developed in collaboration with Claude Code