ksail-bot's sync commit permanently disables Dependabot rebase, stranding ~half of dependency PRs

🤖 Generated by the Agentic Engineer

Evidence

ksail-bot pushes a chore: sync modules and update generated files commit onto Dependabot's own
branches. That single push permanently forfeits Dependabot's ability to rebase the PR:

Looks like this PR has been edited by someone other than Dependabot. That means Dependabot can't
rebase it - sorry!

Observed live on both open Dependabot PRs, 2026-09-01:

PR	sync commit	state
#6830	`ksail-bot` 17:49:13Z	`DIRTY`, checks green, rebase refused 21:03:18Z
#6826	`ksail-bot` 17:31:36Z	`DIRTY`, 38 checks failing, rebase refused 20:03:42Z

Sampling the 12 most recent Dependabot PRs, 7 carry the sync commit (#6814, #6815, #6826, #6827,
#6828, #6829, #6830) and 5 do not (#6812, #6813, #6824, #6825, #6831).

Impact

A Dependabot PR that has been synced cannot recover from base drift on its own. As soon as any other
PR merges to main, it goes DIRTY and stays there — auto-merge is armed but can never fire, and
the ordinary @dependabot rebase remedy is refused. It then needs manual agent intervention every
time.

This is what produced the current queue stall: #6827 merged at 20:26Z and immediately stranded #6830,
which was otherwise green on all 77 checks. The same mechanism previously stranded #6813, whose
closure recreated it as #6826 — so the failure mode also generates PR churn, because closing is the
intuitive-but-wrong remedy (@dependabot recreate rebuilds in place; closing opens a new number).

Because roughly half of Dependabot PRs are affected and the ecosystem is capped at an open-PR limit,
stranded PRs occupy that cap and throttle dependency intake generally.

Expected behaviour

A routine dependency bump should reach merge without agent intervention. Either the generated-file
sync should not land on the Dependabot branch, or it should land in a way that preserves Dependabot's
ownership of the branch.

Options worth weighing:

Move the sync off the PR branch. Let the bump merge as Dependabot authored it and run the
generated-file sync on main afterwards, as its own commit or PR.
Make the sync idempotent and re-appliable, and standardise on @dependabot recreate when the
branch goes stale, accepting that the sync is rebuilt each time.
Gate the sync so it only runs when the bump actually changes generated output, which would cut
the affected share substantially.

Acceptance criteria

A Dependabot PR whose base has moved can recover without an agent comment — either it rebases
itself, or the repository's automation reliably rebuilds it.
Generated files stay correct on main after such a bump merges.
The behaviour is verified on a real bump, not only reasoned about: a PR is observed going stale
and then reaching merge with no agent intervention.

Rough size: M. Worth a short investigation first to decide which of the three options fits the
repository's release and codegen constraints.

🤖 Generated by the Agentic Engineer

@dependabot recreate is confirmed to work as the in-place remedy, measured on both stranded PRs a few minutes after requesting it:

PR	head before → after	state before → after
#6830	`9f01df6bde` → `2972e2841a`	`DIRTY` → `BLOCKED`
#6826	`200115a868` → `b4ef2a48fe`	`DIRTY` → `BLOCKED`

Both PRs kept their number (no churn), the conflict is gone, and they are now merely awaiting checks. So the immediate unstick is cheap and safe — which makes this issue about removing the need for it, not about lacking a workaround.

Note for whoever picks this up: recreate discards the ksail-bot sync commit, so the interesting question is whether ksail-bot re-applies it on the new head and whether the result converges without a second manual nudge. That is worth observing on these two PRs before choosing between the three options in the body.

🤖 Generated by the Agentic Engineer

Correction and a sharper diagnosis — `recreate` alone is NOT a safe remedy

My previous comment said "ksail-bot should re-apply its sync commit on the fresh head." That is wrong, and the opposite appears to be true. Measured ~6 minutes after both rebuilds:

chore(deps): bump github.com/aws/aws-sdk-go-v2/credentials from 1.19.36 to 1.19.38 #6830 commits: dependabot[bot] only.
chore(deps): bump the talos group across 1 directory with 3 updates #6826 commits: dependabot[bot] only.

No ksail-bot sync on either. And #6826's build now fails on exactly the work that commit does:

go: updates to go.mod needed; to update it:
	go mod tidy
##[error]Process completed with exit code 1.

Failing on a fresh base: 🏗️ Build (Linux), 🏗️ Build + cask (macOS), 🔍 Dead Code Analysis, 🛡️ Vulnerability Scan. So the 38 failures on the old head were not base drift — but neither are they a talos incompatibility, which is what I expected to learn. They are the missing sync.

What this means

The dependency loop here has two halves — Dependabot opens the PR, ksail-bot tidies modules and regenerates files — and the second half does not re-fire on a force-push. It appears to trigger on PR open only. So:

action	conflict	build
leave it	`DIRTY` forever	(stale but green)
`@dependabot recreate`	fixed	broken — no sync

recreate therefore trades a stuck PR for a broken one. It is still the right way to clear the conflict, but it is only half a remedy.

The trap for whoever fixes this

The obvious manual unstick — run go mod tidy and push it — reproduces the root cause, because that push is again "someone other than Dependabot" and forfeits rebase all over again. Any fix has to either keep the sync off the PR branch entirely, or make ksail-bot re-fire on synchronize as well as opened.

That makes option 1 in the issue body (run the sync on main after merge, not on the PR branch) look stronger than the other two.

Current state: #6830 has 0 failing with checks still running; #6826 has the 4 failures above. Both are BLOCKED, not DIRTY. Neither should be closed.

🤖 Generated by the Agentic Engineer

Withdrawing my previous comment's central claim — it was inferred too early

I wrote that ksail-bot "does not re-fire on a force-push" and that recreate therefore "trades a stuck PR for a broken one." I do not have evidence for that, and the workflow says the opposite.

What I actually had was a 6-minute window in which no sync commit had appeared. But CI was — and still is — mid-flight on both PRs:

chore(deps): bump the talos group across 1 directory with 3 updates #6826: 🏗️ Build, 🧪 Test, 🧹 Lint, 📊 Code Coverage, 🏗️ Build KSail Binary, 🏠 Home Isolation Guard all in_progress
chore(deps): bump github.com/aws/aws-sdk-go-v2/credentials from 1.19.36 to 1.19.38 #6830: nine checks in_progress, 0 failing

And .github/workflows/ci.yaml triggers on pull_request with no type filter — so synchronize is included — with the sync job gated on github.event_name == pull_request (L763) and only a self-loop guard at L837 (skip if the last commit already is the sync). On that reading the sync should re-fire after a rebuild; it simply had not reached that stage when I looked.

The go mod tidy build failure is consistent with that: the build runs before the sync lands, so an initial red is expected rather than terminal.

What is actually established

✅ ksail-bot's sync commit is what makes Dependabot refuse to rebase — 7 of 12 recent PRs carry it. The issue as filed stands.
✅ @dependabot recreate clears the conflict in place, no new PR number.
❓ Open: whether the sync re-lands on the rebuilt head and the PRs converge green with no further intervention.

That open question is the one worth answering before choosing between the three options in the body — and it is now a concrete observation on two live PRs rather than a hypothesis. My "option 1 looks stronger" conclusion rested on the withdrawn claim; treat the three options as still open.

The one caution I do stand behind: a manual go mod tidy push would re-trigger the non-Dependabot-edit condition, so it is the wrong unstick regardless of how this resolves.

🤖 Generated by the Agentic Engineer

The two PRs have now diverged, and that separates two causes this issue was conflating.

Measured at each PR's current head, newest-run-per-check-name:

PR	head	failing	success	skipped	still running
#6830	`cbb7f7983f`	0	51	16	6
#6826	`7673160e93`	39	18	17	0 (complete)

@dependabot recreate does fix the forfeiture. #6830 carried only the rebase problem, and after the recreate it rebuilt in place and is now clean on every settled check. Its 6 in-flight legs are not yet decided, so this is "0 failing so far", not "green" — but the stranding is demonstrably cleared.

#6826's failures were never the forfeiture. Its CI is complete, and the root cause is a genuine breaking API change in the talos group bump itself:

pkg/fsutil/configmanager/talos/configs.go:615:54: cp.Machine().Kubelet undefined
  (type config.MachineConfig has no field or method Kubelet)
pkg/fsutil/configmanager/talos/configs.go:619:28: cp.Machine().Kubelet undefined
pkg/fsutil/configmanager/talos/version.go:244:28: machineCfg.Kubelet undefined

Everything else red on that PR — Build (Linux), Build + cask (macOS), Code Coverage, Dead Code Analysis, Vulnerability Scan, and all 15 System Test legs — is downstream of that one compile failure.

Why this matters for this issue's framing. The evidence table above currently reads both PRs as instances of the same stranding, with #6826 as the more severe case at "38 checks failing". They are not the same: #6826 needs a code adaptation to the new machinery API and would be red on a perfectly rebased branch too. Its DIRTY state and its red CI are independent problems that happened to coincide.

That does not weaken the issue — the forfeiture is real, reproduced on both, and #6830 shows the remedy costs an agent round-trip every time base moves. It just means #6826 should not be counted as evidence of severity, and its repair is a separate piece of work (adapting to the removed Kubelet accessor), not another recreate.

🤖 Generated by the Agentic Engineer

Measured today: it is not "~half", it is all of them

Every open dependency PR in this repo carried the ksail-bot[bot] chore: sync modules and update generated files commit, and every one was DIRTY:

PR	sync commit	state before
`#6826`	yes	DIRTY
`#6839`	yes	DIRTY
`#6840`	yes	DIRTY
`#6845`	yes	DIRTY

4 of 4. #6839 is the cleanest demonstration that the forfeiture alone is the blocker: it had 0 failing checks and auto-merge armed, and still could not finish, because arming can never fire against a conflicting branch and Dependabot refuses to rebase.

`@dependabot recreate` works as a manual repair — verified on both outcomes

Requested it on the two PRs whose only problem was the conflict:

#6839 rebuilt in place. Same PR number, new head, the ksail-bot commit gone, DIRTY → BLOCKED, 0 failing / 14 pending, auto-merge still armed by ksail-bot. It is now genuinely self-progressing.
#6840 closed itself — "Looks like github.com/aws/smithy-go is up-to-date now, so this is no longer needed." main had already caught up, so recreate correctly retired a stale bump rather than rebuilding it.

Both are correct terminal outcomes, which is the useful part: recreate is safe here. It either rebuilds the branch or retires a bump that is no longer needed, and it does not lose the PR number in the rebuild case. Worth noting against the earlier assumption that recreate always rebuilds in place — it does not, and the exception is benign.

What this does and does not settle

This is a workaround, not a fix — it needs an agent or a human to notice and ask, every time, for every PR. The underlying defect stands: a bot writing to a Dependabot branch permanently forfeits that branch's rebase, so the queue re-strands as soon as main moves.

The remaining two (#6826, #6845) are not repairable this way. They are blocked on the external loft-sh/apiserver dependency tracked in #6776, confirmed from their own build logs — recreating them would just rebuild a branch that still cannot compile.

chore: agent-claim #6832 nonce=e632c38897d4567c8d1c8465067fb05a

ci: leave Dependabot branches to Dependabot so bumps can rebase thems…

Navigation Menu

Repository navigation

ksail-bot's sync commit permanently disables Dependabot rebase, stranding ~half of dependency PRs #6832

Evidence

Impact

Expected behaviour

Acceptance criteria

Correction and a sharper diagnosis — `recreate` alone is NOT a safe remedy

What this means

The trap for whoever fixes this

Withdrawing my previous comment's central claim — it was inferred too early

What is actually established

Measured today: it is not "~half", it is all of them

`@dependabot recreate` works as a manual repair — verified on both outcomes

What this does and does not settle

Metadata

Assignees

Labels

Type

Fields

Projects

Milestone

Relationships

Development

ksail-bot's sync commit permanently disables Dependabot rebase, stranding ~half of dependency PRs #6832

Description

Evidence

Impact

Expected behaviour

Acceptance criteria

Activity

devantler commented on Sep 1, 2026

devantler commented on Sep 1, 2026

Correction and a sharper diagnosis — recreate alone is NOT a safe remedy

What this means

The trap for whoever fixes this

devantler commented on Sep 1, 2026

Withdrawing my previous comment's central claim — it was inferred too early

What is actually established

devantler commented on Sep 1, 2026

devantler commented on Sep 2, 2026

Measured today: it is not "~half", it is all of them

@dependabot recreate works as a manual repair — verified on both outcomes

What this does and does not settle

Metadata

Metadata

Assignees

Labels

Type

Fields

Projects

Milestone

Relationships

Development

Issue actions

Correction and a sharper diagnosis — `recreate` alone is NOT a safe remedy

`@dependabot recreate` works as a manual repair — verified on both outcomes