You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[cocoon] autosubmit triggers merge before all checks have completed in flutter/packages #191610
In a recent Flutter roll to flutter/packages (flutter/packages#12453), the Merge Queue Guard was marked as passing before the Dashboard Checks had completed. When the autosubmit label was added, the PR was then erroneously merged before all the checks had passed, leading to a flutter/packages tree closure.
The reason of this failure is due to infra issues the number or remaining_jobs in presubmit_guards table become 0 before all jobs are processed.
The suggestion is to stop using failed_jobs == 0 and remaining_jobs == 0 condition to unlock Merge Queue Guard and instead check jobs map that all the jobs are in 'Succeeded' state.
This just happened again with flutter/packages#12627 (I added autosubmit before the checks had completed, and it was auto-merged immediately). Could we bump this up to a P1? Thank you!
It has always done this for non-merge queue projects (like flutter/packages).
Autosubmit should look at all scheduled tests and not merge unless they are green. This should have included dashboard checks since it was in the failed state.
While I'm working on switching Dashboard Checks back to in progress instead of neutral, we can mark Merge Queue Guard as required check as a temporary solution.
@jtmcdole you marked Merge Queue Guard as required for packages repo, that should solve the issue. Now while I'm working on permanent solution of switching Dashboard Checks in progress we several options:
Switch Dashboard Checks to neutral state once all failed jogs re-run but keep Merge Queue Guard in in-progress. Which improve usability (user can apply autosubmit label and have some kind of notification in github UI that jobs are running. See: Ergonomics of re-runs + autosubmit are worse under unified checks #191005);
Keep Dashboard Checks in failed state. less usability but more error pruned solution;
Do not fail Dashboard Checks but publish comment with error in PR;
Do not fail Dashboard Checks but either create new Presubmit check and once first job failed and mark it as failed and if re-run all recreate it in in-progress state.
My feeling is that we should leave the Dashboard Checks in a failed state until we have a long-term solution (switching back to in-progress). Marking as neutral just seems like the wrong thing here, as it unblocks the check. The Merge Queue Guard is temporarily mitigating this problem in the packages repo, but since the neutral status actually changes the check to non-blocking, it seems like too much of a footgun. I think it's important that Dashboard Checks blocks merges if it fails first and foremost, regardless of whether Merge Queue Guard is present on the repo.
I opened a PR that removes the neutral status change here: flutter/cocoon#5154
I merged flutter/cocoon#5154 yesterday, which deployed today, which makes it so that Dashboard Checks no longer is marked as neutral on re-run, so we shouldn't have to rely on the MQG anymore. Whether that would have prevented #193132 I guess depends on whether "rerun" was clicked.
This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of flutter doctor -v and a minimal reproduction of the issue.
Activity
ievdokdm commentedon Aug 25, 2026
@elliette is
Merge Queue Guardbecome green right afterautosubmitlabel was added ?elliette commentedon Aug 25, 2026
Based on the timestamps on flutter/packages#12453, it looks like
autosubmitlabel was added before the Merge Queue Guard became green:engine-flutter-autorollbot addedautosubmitlabel at 4:57 PM:Merge Queue Guard went green at 5:36 PM:
ievdokdm commentedon Aug 25, 2026
The reason of this failure is due to infra issues the number or
remaining_jobsinpresubmit_guardstable become 0 before all jobs are processed.The suggestion is to stop using
failed_jobs == 0andremaining_jobs == 0condition to unlockMerge Queue Guardand instead checkjobsmap that all the jobs are in'Succeeded'state.elliette commentedon Aug 26, 2026
This just happened again with flutter/packages#12627 (I added
autosubmitbefore the checks had completed, and it was auto-merged immediately). Could we bump this up to a P1? Thank you!Piinks commentedon Aug 26, 2026
cc @jtmcdole should this be P0/1? Changes are being merged before checks are completing
jtmcdole commentedon Aug 26, 2026
It has always done this for non-merge queue projects (like flutter/packages).
Autosubmit should look at all scheduled tests and not merge unless they are green. This should have included dashboard checks since it was in the failed state.
jtmcdole commentedon Aug 26, 2026
@ievdokdm - status "neutral" is considered a success.
log link
{"name":"Dashboard Checks","id":98249538743,"external_id":"","status":"completed","head_sha":"","check_suite":{"id":89374097924},"details_url":"https://flutter-dashboard.appspot.com/#/presubmit?repo=packages&sha=a50e83b5e4bdf7ad4b036127fea428452e1e9ed6","started_at":"2026-08-26T16:57:29.000Z","conclusion":"neutral"}jtmcdole commentedon Aug 26, 2026
flutter/packages#12453 was merged at 17:58 - the logs show that Dashboard Checks was "success" - which comes from GitHub Checkruns.
Autosubmit performed as expected here.
ievdokdm commentedon Aug 26, 2026
@jtmcdole flutter/packages#12453 was merged on August 13, but neutral status was landed on August 20 and flutter/packages#12627 was merged because of added
emergencylabel9 remaining items
jtmcdole commentedon Sep 17, 2026
Increasing priority.
jtmcdole commentedon Sep 17, 2026
a rerun was triggered, setting the result to neutral
autosubmit bot shows neutral after being queued for several runs.
ievdokdm commentedon Sep 18, 2026
While I'm working on switching
Dashboard Checksback to in progress instead of neutral, we can markMerge Queue Guardas required check as a temporary solution.ievdokdm commentedon Sep 21, 2026
@jtmcdole you marked
Merge Queue Guardas required for packages repo, that should solve the issue. Now while I'm working on permanent solution of switchingDashboard Checksin progress we several options:Dashboard Checkstoneutralstate once all failed jogs re-run but keepMerge Queue Guardin in-progress. Which improve usability (user can applyautosubmitlabel and have some kind of notification in github UI that jobs are running. See: Ergonomics of re-runs +autosubmitare worse under unified checks #191005);Dashboard Checksin failed state. less usability but more error pruned solution;Dashboard Checksbut publish comment with error in PR;Dashboard Checksbut either create newPresubmitcheck and once first job failed and mark it as failed and if re-run all recreate it in in-progress state.eyebrowsoffire commentedon Sep 21, 2026
My feeling is that we should leave the Dashboard Checks in a failed state until we have a long-term solution (switching back to in-progress). Marking as neutral just seems like the wrong thing here, as it unblocks the check. The
Merge Queue Guardis temporarily mitigating this problem in the packages repo, but since the neutral status actually changes the check to non-blocking, it seems like too much of a footgun. I think it's important thatDashboard Checksblocks merges if it fails first and foremost, regardless of whetherMerge Queue Guardis present on the repo.I opened a PR that removes the neutral status change here: flutter/cocoon#5154
Don't mark dashboard checks as neutral on rerun. (flutter#5154)
elliette commentedon Sep 21, 2026
Not sure if this is the same underlying cause - dashboard checks were marked as green here despite still running: flutter/packages#12959
(Again, causing
autosubmitto erroneously submit the PR)Dashboard here
Piinks commentedon Sep 21, 2026
Yeah this one seemed a bit different. Filed details in #193132
Piinks commentedon Sep 21, 2026
The MQG did not block it then because it was definitely reporting green
eyebrowsoffire commentedon Sep 22, 2026
I merged flutter/cocoon#5154 yesterday, which deployed today, which makes it so that
Dashboard Checksno longer is marked as neutral on re-run, so we shouldn't have to rely on the MQG anymore. Whether that would have prevented #193132 I guess depends on whether "rerun" was clicked.eyebrowsoffire commentedon Sep 28, 2026
We've put fixes to mitigate the original issue here, so we're going to close this one.
The issue with the checks being green while in progress can be tracked here: #193132
github-actions commentedon Oct 12, 2026
This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of
flutter doctor -vand a minimal reproduction of the issue.