Before you press rerun on a red fix PR, compare it with the main branch, read the actual failure message, and look at what the update really changed. A test that "looks unrelated" is often related through a transitive package. A rerun is fine only after you know why it failed.
Why a red fix PR deserves a few minutes
The point of a test gate on bot PRs is that it says no for you. If the habit becomes "rerun until green", the gate stops carrying information. Automerge tools make this sharper: Renovate's documentation says it waits for the required tests to pass before it automerges. A flaky pass can therefore put a change into main that no person looked at.
Step 1: Does main pass right now?
Open the latest CI run on the main branch. If main is red, your fix PR did not break anything new, and the real job is to fix main. If main is green, the PR changed something. Move on.
Step 2: Read the failure, do not skim it
Sort the failure into a type, because each type has a different next step.
| Failure type | What it usually means | Next step |
|---|---|---|
| Import or module not found | A package was renamed, split or dropped a file | Read the release notes for the package |
| Assertion on output format | A library changed default formatting or ordering | Update the test only if the new output is correct |
| Type or compile error | An API changed, even in a minor release | Treat as a breaking change, not a patch |
| Timeout or network error | Environment, not code | Rerun once and record it |
| Passes on rerun, fails again later | Flaky test | Track it, do not merge on luck |
If the update claims to be a patch release but causes a compile error, that tells you something about the package. See can a security fix be a breaking change in semver.
Step 3: Look at what changed beyond the named package
Open the lockfile diff. One bump in the manifest can move several transitive packages. The failing test may exercise one of those. If the diff is large, the failure points to the likely culprit, and you can test by pinning that transitive package back to its old version in a scratch branch.
Step 4: Decide what the test is telling you
There are three honest outcomes.
- The test caught a real break. Fix the code, or hold the update, and write down why.
- The test is wrong or brittle. Fix the test in a separate pull request so the cause is reviewed on its own.
- The test is flaky. Rerun once, log the flake, and file a task to repair it. If flakes are frequent, read flaky security tests: why retries hide bugs.
Do not edit the test inside the bot's branch unless your tool allows human commits there. Dependabot, for instance, stops rebasing once extra commits are pushed, unless the commit message carries a skip marker, so mixed edits can confuse the branch.
What to write in the PR
A one line note helps the next person: "Red on test X, main green. Cause: library Y changed ordering. Updated test in PR 123." That is cheap, and it is also evidence that a human looked.
Try it yourself
Open the pull request gate and watch which checks block a change and which only warn. Notice that a failing check stops the merge until someone makes a decision.
Click through it at your own pace, or open it full screen.
Safeguard can open fix pull requests through autonomous remediation. It is off by default and every category starts on Manual, so a person approves each change. You can also run a free scan to see which dependencies have known fixes before you decide what to automate.
Quick check
Is one rerun ever acceptable?
Yes, for a clear environment failure such as a network timeout. Record it. If the same test fails again, treat it as a signal.
Should I disable the failing test to get the fix merged?
Not as a shortcut. If the test is wrong, fix it in a reviewed change. A silently disabled test hides the next real break.
Sources
- Renovate Docs: Automerge configuration and troubleshooting
- GitHub Docs: Managing pull requests for dependency updates
Last reviewed: 19 October 2026.
