Dependabot's weekly npm run wedges whenever a patch is 3-7 days old: cooldown default-days (7) exceeds semver-patch-days (3)

[lukaso-bot]

The weekly npm update run has been failing since 2026-08-21, and it is the only channel this repo has for getting a CVE fix into the manifests.

What happened

Run 32530532534 (2026-08-21T21:52:56Z) exited with 9 errors and opened nothing. Every dependency in the group failed with the same message:

ERR_PNPM_NO_MATCHING_VERSION  No matching version found for vitest@^4.1.11 published by
Fri Aug 14 2026 21:56:22 ... Version 4.1.11 satisfies the specs but was released at
Tue Aug 18 2026 14:27:07

Root cause

.github/dependabot.yml sets cooldown.default-days: 7 alongside semver-patch-days: 3. Dependabot selects a candidate using the granular value but passes default-days to pnpm as the resolver floor — the log shows --config.minimumReleaseAge=10080 (10080 minutes = 7 days), and the cutoff it prints is run-time minus 7 days.

vitest 4.1.11 was 3.3 days old at run time. That passes semver-patch-days: 3, so Dependabot wrote ^4.1.11 into packages/cli/package.json. It fails the 7-day resolver floor, so pnpm could not resolve the range it had just been handed.

pnpm resolves the workspace with -r, so that single unsatisfiable range took down every other update in the run: @types/node, hono, @axe-core/playwright, @cloudflare/workers-types, axe-core, playwright, smol-toml, wrangler, @cloudflare/vitest-pool-workers.

Why it looks like flake

It fires whenever any dependency's newest release is aged between 3 and 7 days. Patch releases land constantly, so the weekly run fails on an effectively random schedule — 2026-08-14 green, 2026-08-21 red.

Why it matters here

Dependabot security alerts are disabled on this repo (GET /dependabot/alerts returns 403 "Dependabot alerts are disabled for this repository"). The weekly grouped version update is the only path by which a dependency fix reaches the manifests. Right now hono ^4.12.32 carries 4 MEDIUM CVEs (GHSA-54fx, -79qm, -8j4g, -f23p; fixed in 4.12.34) with no PR raised for it. The osv CI gate still catches High/Critical, so detection is intact — it is the update channel that is down.

Fix

.github/dependabot.yml is engine-managed (# liveapp-dependabot-version: 2), so this is not patched in-repo — the next engine config upgrade would re-deliver the shipped file and drop the edit. Routed upstream as engine feedback.

The change is one line: default-days must not exceed the smallest semver-*-days value.

cooldown:
  default-days: 3        # was 7
  semver-major-days: 30
  semver-minor-days: 7
  semver-patch-days: 3

This does not shorten any soak. What the repo adopts is still governed by the selection cooldowns (patch 3 / minor 7 / major 30); default-days only sets the resolver floor during Dependabot's own install.

Meanwhile

Two things worth a decision, both yours:

1. Turn on Dependabot alerts (Settings → Code security), so a CVE has a channel that does not depend on the weekly run succeeding.
2. hono 4.12.34 — if the next weekly run (Fri 2026-08-28) still raises no hono PR, it is worth bumping by hand rather than waiting for the upstream config fix to land.

[lukaso-bot]

Recurred on the 2026-08-28 weekly run (job 33214471336, 21:53:06Z). npm_and_yarn in /. and github_actions in /. green; the grouped job red again. Second consecutive week, as predicted.

The log refines the mechanism, so recording it rather than just noting the recurrence — one part of the original diagnosis was wrong.

Dependabot is passing the granular value for patches. Every patch bump in this run ran with --config.minimumReleaseAge=4320 (3 days = semver-patch-days: 3), not 10080:

pnpm update @biomejs/biome@2.5.10 ... --config.minimumReleaseAge=4320
pnpm update publint@0.3.24      ... --config.minimumReleaseAge=4320
pnpm update vitest@4.1.11       ... --config.minimumReleaseAge=4320
pnpm update tsx@4.23.12         ... --config.minimumReleaseAge=4320

So "Dependabot selects with the granular value but passes default-days to pnpm" is not what happens. The 7-day value is passed only for the non-patch updates, which is correct behaviour.

The actual failure is the two windows disagreeing within one job. The red step is the @types/node@26.2.0 minor bump, which correctly gets --config.minimumReleaseAge=10080:

ERR_PNPM_NO_MATCHING_VERSION  No matching version found for picomatch@4.0.7
published by Fri Aug 21 2026 21:54:40 GMT+0000 ... Version 4.0.7 satisfies the
specs but was released at Mon Aug 24 2026 14:36:23 GMT+0000
This error happened while installing the dependencies of vitest@4.1.11

Read that last line carefully: the rejected package is picomatch, a transitive dependency of vitest@4.1.11 — the patch this same job had already applied one step earlier under the 3-day window. The 3-day window admitted vitest@4.1.11; three steps later the 7-day window refuses a transitive dep that vitest@4.1.11 requires. The job contradicts itself.

Why that matters for the fix. The earlier note framed this as "any dep aged 3–7 days wedges the run", which suggested simply widening semver-patch-days. It is narrower and more structural than that: any patch admitted under the short window whose transitive closure contains a package newer than the long window wedges the next non-patch update in the same job. Raising semver-patch-days to 7 would fix it by collapsing the two windows into one; lowering default-days to 3 would too. Having two different values at all is the defect — pnpm applies minimumReleaseAge to the whole resolution graph, not just the named package, so the windows cannot differ per-update within a shared lockfile.

Still engine-side (dependabot.yml is engine-managed, liveapp-dependabot-version: 2); the engine-feedback note dependabot-cooldown-default-days-wedges-pnpm.md should be read together with this correction.

No action taken here — tracking the recurrence and the sharper mechanism. Expect RED again next Friday until the engine fix lands.

[lukaso-bot]

Recurred on the 2026-09-04 weekly run (job 33923076759, 21:52:43Z). Third consecutive week. npm_and_yarn in /. and github_actions in /. green; the grouped job red with 8 errors.

The root cause is unchanged and settled — two different cooldown windows inside one job run — so this is a recurrence note, not a re-diagnosis. But this week's log sharpens one detail, and contradicts a caveat I added on 2026-08-28, so it is worth correcting rather than leaving to mislead the next reader.

What I said last time

the rejected package is usually a TRANSITIVE dep (e.g. picomatch) pulled in by a PATCH the same job already applied … so do not expect the rejected version itself to be the patch.

What happened this week

The rejected package is the patch the job applied, and it is a direct dependency:

pnpm update @axe-core/playwright@4.13.0 ... --config.minimumReleaseAge=10080
  ERR_PNPM_NO_MATCHING_VERSION  No matching version found for tsx@^4.23.13
  published by Fri Aug 28 2026 21:55:02 GMT+0000 ...
  Version 4.23.13 satisfies the specs but was released at Sun Aug 30 2026 00:46:16
  This error happened while installing a direct dependency of .../packages/cli

tsx@4.23.13 was published 2026-08-30 — 5 days old at run time, so it cleared semver-patch-days: 3 and Dependabot wrote ^4.23.13 into packages/cli/package.json. Every later non-patch step then runs under --config.minimumReleaseAge=10080 (7 days, cutoff Fri Aug 28 21:55 = run-time minus 7), and that window refuses the very range the same job just wrote. All 8 failures are the identical tsx error, one per non-patch step (hono, @axe-core/playwright, @cloudflare/workers-types, axe-core, playwright, smol-toml, wrangler, @cloudflare/vitest-pool-workers).

So the trigger is broader than either previous description

It is not "a transitive of a patch" and not "any dep aged 3–7 days". It is: any package admitted under the short window that is still newer than the long window — whether it lands as a direct requirement (this week, tsx) or is dragged in transitively (last week, picomatch under vitest). Both are the same defect seen from different sides.

The fix is unchanged: make default-days and the smallest semver-*-days equal, so one job cannot resolve under two windows. dependabot.yml is engine-managed, so it stays routed upstream.

Related, from the same run

The grouped job did open #167 for the patch group before dying on the non-patch steps. #167's osv dependency scan was then red on fflate@0.7.4 (GHSA-px8p-9vwx-vf98, High) — a condition already on main, not caused by the bump. Fixed with an override on that branch; #167 is now green and mergeable.

hono ^4.12.32 still carries its four MEDIUM advisories (fixed in 4.12.34) with no PR, for the third week running — this wedge is why. Those do not gate CI (High/Critical only), so they are visible but unshipped.