fix: keep the pull request comment in sync when a config change skips redeploy - #241
Merged
vigneshrajsb merged 6 commits intoAug 28, 2026
Merged
Conversation
Config changes applied through the API or UI on an environment with deploys disabled never queued a redeploy, so the GitHub Mission Control comment was never regenerated. The comment kept showing the old state, and the next manual edit to it silently reverted the change. Force a comment refresh whenever a change is persisted but no redeploy gets queued, in both entry paths: BuildService's API patch flow, and OverrideService's direct config/service override calls used by the legacy build patch routes. Both paths check the same queue-vs-no-queue outcome so a single request never enqueues two comment jobs.
PATCH /api/v2/environments/{uuid} discarded the result of applying the
patch, so a client could not tell whether its request actually queued
a redeploy. This mattered when submitted service overrides matched
the current state and were dropped as no-ops.
The response now adds redeployQueued (boolean) and, when true,
deployId, alongside the existing environment detail fields. GET keeps
its original response shape.
The refresh takes its own lock on the same build, so running it while the deployment lock was still held meant a slow comment update could block every other operation on that build. It now runs after the lock is released. Also widen the error handling to cover the whole refresh, not just the request.
Hoisting the result out of the lock callback widened mode to string, which no longer matched the declared result type and broke the build.
vigneshrajsb
force-pushed
the
fix/mission-control-comment-refresh-without-redeploy
branch
from
August 28, 2026 22:43
d75ac37 to
61fe8cc
Compare
The two write paths decide when to refresh at different levels, so both call sites stay, but the body now lives once alongside the other comment helpers.
vigneshrajsb
force-pushed
the
fix/mission-control-comment-refresh-without-redeploy
branch
from
August 28, 2026 22:44
61fe8cc to
9eba144
Compare
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
Two changes to how environment config updates behave.
The pull request comment could go stale. The comment is rebuilt from the database, but that only happened when a build or deploy changed status. A config change on an environment with deploys paused updated the database and queued nothing, so the comment kept showing the old selections. Editing that stale comment then reapplied the old state and silently undid the change. The comment is now refreshed whenever a config change is applied without queueing a redeploy.
The patch response did not say whether a redeploy started.
PATCH /api/v2/environments/{uuid}already knew, but threw the answer away, so clients had to guess fromdeployEnabled. That guess is wrong when the server drops the submitted overrides as no-ops. The response now carriesredeployQueuedand, when one started,deployId.Notes
The comment refresh is queued rather than rendered inline, and it runs after the build deployment lock is released. It takes its own lock on the same build, so holding both would let a slow comment update block other operations on that build. Any failure in it is caught and logged, so it cannot fail the config request.
redeployQueuedanddeployIdare added as new schema components used only by the patch operation. The shared environment detail schema and the GET response are unchanged.Testing
Unit tests cover both outcomes for each change. Verified on a live environment: a config change with deploys paused returned
redeployQueued: falseand the comment refreshed within about 15 seconds, and a no-op patch returnedredeployQueued: falsewhiledeployEnabledwas still true.