40 Dependabot pull requests across 10 fleet repos cannot merge, and cannot be made to merge by any means short of a repository settings change. Most are security updates. This issue records the diagnosis so the next person does not have to re-derive it.
The state
| Repo |
Stuck PRs |
Oldest |
| zaakafhandelapp |
12 |
|
| filinq |
11 |
|
| openregister |
4 |
2026-05-08 |
| opencatalogi |
3 |
2026-05-08 |
| integriq |
3 |
|
| dossiq |
2 |
|
| planninq |
2 |
|
| thematiq |
1 |
|
| stackiq |
1 |
|
| launchpad |
1 |
|
All target main. All fail branch-protection / check-branch, which accepts only beta and hotfix/* into main. They have been accumulating since May.
Why it happens
Dependabot security updates always open against the repository's default branch. These 10 repos default to main. The fleet's branch protection refuses anything into main that is not beta or hotfix/*. So every security PR is unmergeable the moment it is created.
The 11 fleet repos that default to development (larpinq, pipelinq, shillinq, learniq, portaliq, decidiq, buildiq, keepiq, hermiq, humaniq, versioniq) have zero stuck Dependabot PRs. The split is exactly the default branch.
What does not work, measured
🔴 Adding target-branch: "development" does not fix this. It applies to version updates only. GitHub's own documentation says, of configuring Dependabot for security updates: "you should not specify a target-branch." Note the config on development in these repos already carries target-branch — it was set on a branch Dependabot never reads, because Dependabot reads the default branch.
🔴 Retargeting the PR to development does not work. main and development have diverged in both directions (main 6 to 37 commits ahead, development 260 to 5,744 ahead). Measured on stackiq#465: retargeting turned a 2-file, +138/-702 dependency bump into a 36-file, +2,256/-704 CONFLICTING PR that dragged in main-only workflow and openspec files. Reverted.
🔴 Rebasing or cherry-picking the bump onto development does not work. The Dependabot commit is clean in isolation (package-lock.json + package.json only), but cherry-picking it onto development conflicts on both files. A lockfile is a generated artefact: it has to be regenerated against the target tree, not replayed from a four-month-old diff.
🔴 Closing them is not neutral. Closing a Dependabot PR suppresses that version rather than deferring it. These are security updates covering dompurify, postcss, ajv, qs, brace-expansion, follow-redirects, fast-xml-parser, node-forge and websocket-driver.
The only fix
Change the default branch of the 10 repos to development, matching the 11 that already work. Dependabot's security PRs then open against development, where branch protection accepts them, with lockfiles computed against the tree they will actually merge into.
Then close the 40 stale PRs so Dependabot recreates them correctly.
Deliberately not done in this session: it is a visible repository settings change (it changes what the repo page shows and where fresh clones land), so it wants a decision rather than a drive-by.
Until then
These repositories are not receiving dependency security updates in any mergeable form. That is the cost of leaving it, and it is worth being explicit about rather than letting 40 red PRs read as noise.
40 Dependabot pull requests across 10 fleet repos cannot merge, and cannot be made to merge by any means short of a repository settings change. Most are security updates. This issue records the diagnosis so the next person does not have to re-derive it.
The state
All target
main. All failbranch-protection / check-branch, which accepts onlybetaandhotfix/*into main. They have been accumulating since May.Why it happens
Dependabot security updates always open against the repository's default branch. These 10 repos default to
main. The fleet's branch protection refuses anything intomainthat is notbetaorhotfix/*. So every security PR is unmergeable the moment it is created.The 11 fleet repos that default to
development(larpinq, pipelinq, shillinq, learniq, portaliq, decidiq, buildiq, keepiq, hermiq, humaniq, versioniq) have zero stuck Dependabot PRs. The split is exactly the default branch.What does not work, measured
🔴 Adding
target-branch: "development"does not fix this. It applies to version updates only. GitHub's own documentation says, of configuring Dependabot for security updates: "you should not specify atarget-branch." Note the config ondevelopmentin these repos already carriestarget-branch— it was set on a branch Dependabot never reads, because Dependabot reads the default branch.🔴 Retargeting the PR to
developmentdoes not work.mainanddevelopmenthave diverged in both directions (main 6 to 37 commits ahead, development 260 to 5,744 ahead). Measured on stackiq#465: retargeting turned a 2-file, +138/-702 dependency bump into a 36-file, +2,256/-704 CONFLICTING PR that dragged in main-only workflow and openspec files. Reverted.🔴 Rebasing or cherry-picking the bump onto
developmentdoes not work. The Dependabot commit is clean in isolation (package-lock.json+package.jsononly), but cherry-picking it onto development conflicts on both files. A lockfile is a generated artefact: it has to be regenerated against the target tree, not replayed from a four-month-old diff.🔴 Closing them is not neutral. Closing a Dependabot PR suppresses that version rather than deferring it. These are security updates covering dompurify, postcss, ajv, qs, brace-expansion, follow-redirects, fast-xml-parser, node-forge and websocket-driver.
The only fix
Change the default branch of the 10 repos to
development, matching the 11 that already work. Dependabot's security PRs then open againstdevelopment, where branch protection accepts them, with lockfiles computed against the tree they will actually merge into.Then close the 40 stale PRs so Dependabot recreates them correctly.
Deliberately not done in this session: it is a visible repository settings change (it changes what the repo page shows and where fresh clones land), so it wants a decision rather than a drive-by.
Until then
These repositories are not receiving dependency security updates in any mergeable form. That is the cost of leaving it, and it is worth being explicit about rather than letting 40 red PRs read as noise.