Dependabot has no cooldown, so it opens PRs into a 7-day install guard that rejects them

[tps-flint]

Dependabot opens PRs into a bake window that will reject them

The install step runs under a minimum release age of 7 days (604800 seconds), enforced at install time. Dependabot has no matching cooldown, so it opens a PR the moment a version publishes — into a guard that is guaranteed to refuse it.

The failure is unambiguous once you get past the log noise:

error: No version matching "typebox" found for specifier "1.3.14"
       (blocked by minimum-release-age: 604800 seconds)
error: typebox@1.3.14 failed to resolve
FAILED STEP: Run sfw bun install --frozen-lockfile

Confirmed on at least two open PRs with different ecosystems, so this is the mechanism rather than a one-off.

Neither component is misbehaving. The bake window is a deliberate supply-chain control and should stay. Dependabot is doing exactly what it is configured to do. The defect is that the two were never told about each other.

Why this produces a backlog rather than a blip

A PR blocked this way does not recover on its own. The version ages past the window within days, at which point the same PR would very likely pass — but nothing re-runs it. It stays red, accumulates, and reads like a broken dependency rather than a timing artifact.

The oldest open PR here dates from May. The most recent blocked one proposes a version that is now nine days old — comfortably past the window, still red, because the failing run is from the day it opened.

The second-order cost is worse than the queue itself: a wall of red dependency PRs trains everyone to stop reading them. When a genuinely broken bump appears, it looks exactly like the other nine.

Fix

Give Dependabot a cooldown that matches or exceeds the install guard, so it opens PRs only once a version can actually install. .github/dependabot.yml already sets schedule, groups and PR limits; this is the missing knob, not a restructure.

The two windows should be defined in terms of each other, or at minimum documented together with a comment on each pointing at the other — otherwise the next person to tune one silently re-creates this.

Also needed, separately

Re-run CI on the currently-blocked PRs whose versions have since aged out. Several are likely green now with no code change at all. Worth doing before anyone judges whether the bumps themselves are sound, since right now a timing artifact and a real breakage are indistinguishable at a glance.

Note: at least two of the open failures are not bake-age and have distinct causes. Those want individual attention and should not be swept into a bulk re-run.

Check

After the change, a freshly published version must produce no PR until it clears the window — and the first PR that does appear must install cleanly on its first run.

Assert both halves. A cooldown that is simply longer than anyone tests will look identical to a cooldown that works, right up until it does not.

[tps-flint]

This is a loop, not a backlog — and I proved it by walking into it

I tried to clear these by hand and made it worse. Documenting that, because it turns this issue from housekeeping into the only available fix.

What I did: the blocked PRs proposed versions that had since aged past the window, so a re-run should have passed. It didn't — a second blocker was behind the first:

error: lockfile had changes, but lockfile is frozen

The branches were stale against main, so --frozen-lockfile rejected the drift. The standard remedy is a rebase. I rebased them.

What the rebase did:

before:  typebox 1.3.14   blocked by minimum-release-age
after:   typebox 1.3.16   blocked by minimum-release-age

The rebase bumped to the newest published version, which is fresh, so the guard blocks it again. The bake clock resets to zero on the exact action required to fix the staleness.

Why that makes these structurally unmergeable

The two failure modes have mutually exclusive remedies:

• Wait → the version ages past the window, but the branch drifts further from main and the frozen lockfile check starts failing
• Rebase → the lockfile drift is fixed, but the version is now the newest release and the bake window restarts

There is no ordering of "wait" and "rebase" that satisfies both. Every attempt to unstick one of these re-sticks it, which is why they have accumulated since May rather than being cleared by anyone diligent. It was never a matter of attention.

So the cooldown is not a tidy-up, it is the fix

Without it, no amount of manual intervention converges — a maintainer can burn an afternoon here and end exactly where they started, which is roughly what I just did in miniature.

With Dependabot holding a PR until the version clears the window, it opens already-installable, the frozen lockfile matches because the branch is fresh, and both failure modes are gone at once rather than traded against each other.

Consequence for the current queue

Do not rebase the remaining blocked PRs. It will re-arm the same trap on each one. Land the cooldown first, then let Dependabot recreate them — at that point they open green.

The one exception worth checking by hand: #58 fails on analyze (javascript-typescript), not the install guard. Different cause, unaffected by any of this, and it is the only one in the set that might be a real defect.

[tps-flint]

Correcting the premise here, because acting on it alone would not have worked.

This issue says dependabot opens PRs into a 7-day install guard that rejects them. That was accurate when filed, and the cooldown is still worth adding. But it was the first blocker, not the only one — and as of today it is no longer the active one.

Re-derived on #88 just now. Its version has aged well past the 7-day window, so bake-age can no longer be the cause. The PR is still red, and the error is different:

error: lockfile had changes, but lockfile is frozen

Dependabot edits package.json and never touches bun.lock, and CI runs sfw bun install --frozen-lockfile. All four open npm PRs (#88, #87, #48, #12) are package.json-only. That fails on the first run and every run after, regardless of how long anyone waits.

Filed separately as #103, since it is a distinct mechanism with a distinct fix.

Why this matters for the plan recorded here: shipping the cooldown and stopping would have left these PRs red, and it would have looked like the cooldown did not work. The cooldown prevents a future class of failure; #103 is what actually unblocks the current four.

Keeping this open — the cooldown is still the right fix for what it describes, and the two windows should still be defined in terms of each other. Just not the whole story.

[tps-flint]

This is now the only remaining blocker, and it has changed shape — for the better. Evidence from the first dependabot run after #106 switched the ecosystem to bun.

The chain resolved down to this issue

Three layers were stacked on the four stalled npm PRs. Two are gone:

• Dependabot updates package.json but never bun.lock, so every npm PR fails --frozen-lockfile #103 (manifest without lockfile) — fixed. fix(deps): declare the bun ecosystem, and group codeql-action #106 declared package-ecosystem: bun. Confirmed observationally within minutes: the new PRs chore(deps-dev): bump the typescript-ecosystem group across 1 directory with 2 updates #108, chore(deps): bump croner from 9.0.0 to 10.0.1 #109, chore(deps): bump @earendil-works/pi-coding-agent from 0.79.10 to 0.84.2 #110 each touch bun.lock, package.json. That was the exact assertion, and it passed.
• bunfig minimumReleaseAge exclusion covers @biomejs/biome but not its platform binaries, so lockfile regeneration breaks CI #67 (unsatisfiable biome exclusion) — fixed by fix(deps): drop the unsatisfiable biome bake-age exclusion #105.
• This issue — now the active blocker, and the last one.

What changed about how it fails

Dependabot's bun updater runs bun install / bun update inside the repo, so it reads bunfig.toml — including minimumReleaseAge = 604800. Two packages resolve to versions inside the 7-day window and hard-fail:

ERROR Error running bun command: bun update typebox@1.3.17 --save-text-lockfile --ignore-scripts
  error: No version matching "typebox" found for specifier
  → dependency_file_not_resolvable

ERROR Error running bun command: bun update @biomejs/biome@2.5.10 --save-text-lockfile --ignore-scripts
  → dependency_file_not_resolvable

##[error]Dependabot encountered an error performing the update

The old failure mode: dependabot opened a PR that could never install, and it sat red indefinitely. The new one: dependabot refuses to open the PR and reports an error. That is strictly better — no unmergeable PR is created — but it turns the Dependabot lane on main red.

Note the biome half is a direct, predicted consequence of #105. Dropping the biome bake exclusion was deliberate and reviewed; the accepted trade was that biome updates wait 7 days like everything else. This is that trade arriving. Not a regression — the exclusion was unsatisfiable anyway.

Why the red lane matters more than it looks

A permanently-red lane on main is the failure mode this whole cluster keeps producing. It trains people to stop reading the signal, and then a genuine break looks identical to the standing one. Fixing the cause matters more here than the individual bumps.

The fix, unchanged in substance

Give dependabot a cooldown at least as long as the install guard, so it only proposes versions that can actually install. Both windows should be defined in terms of each other, or at minimum carry comments pointing at each other — otherwise the next person to tune one silently recreates this.

Check

Two halves, and both are needed:

1. A freshly published version must produce no PR and no dependabot error until it clears the window.
2. The first PR that does appear must install cleanly on its first run — no re-run.

Assert both. A cooldown merely longer than anyone tests looks identical to one that works, right until it doesn't. And a cooldown that silences the error while still skipping the bump would satisfy (1) alone while leaving us permanently behind.

This must fail against today's config: the Dependabot lane is red on main right now for exactly this reason, which is the known-answer case.

Refs #103
Refs #67
Refs #106