Symptom
npm run deps:check exits 1 on main with 5 cargo deps newer than the 7-day threshold:
[cargo] serde@1.0.229 too new (0.8d, need >=7d)
[cargo] tokio@1.53.0 too new (2.5d, need >=7d)
[cargo] uuid@1.24.0 too new (3.9d, need >=7d)
[cargo] anyhow@1.0.104 too new (0.9d, need >=7d)
[cargo] futures@0.3.33 too new (1.3d, need >=7d)
5 dependency(s) younger than 7 days. Blocked.
Same Cargo.lock entries on main fail the same gate (verified locally on the unchanged main checkout, see PR #222 follow-up note).
Impact
The deps-age GitHub Actions job runs npm run deps:check whenever any npm file changes. With these versions, the gate stays red until either:
- All 5 deps age past 7 days (auto-resolves ~6 days from now at most), OR
- A maintainer action (re-bump, lock-file pin, or script tweak).
Until then, any PR touching package.json or package-lock.json is blocked. PR #222 had to dodge this by structuring its changes carefully; this will bite future PR work.
Why is this happening?
Likely caused by a Dependabot group bump (e.g. #205 which fix(deps): resolve 9 of 28 cargo-audit advisories) that landed these crate versions very recently. The 7-day MIN_AGE_DAYS gate is enforced uniformly across all deps; transitives on the lockfile get checked via the resolved-version lookup in scripts/check-deps.mjs.
Possible fixes
- Wait it out — these will clear as days pass. Cheap but uncertain (any new dep bump resets the timer).
- Tighten Dependabot cadence — stagger updates so at most one new dep per day; trivial in dependabot.yml
schedule config.
- Adjust the script to skip 'too-new' for newly-bumped security fixes — could add a 'grace' list like the
KNOWN_ACCEPTED array in scripts/cargo-audit-check.sh.
- Document the expectation that recent security fixes will trip the 7-day gate, and gate PRs by urgency rather than blanket blocking.
Suggested approach
Option 1 + Option 2 combined: let these clear naturally, then add a Dependabot schedule that spreads out major-version group bumps so the 7-day buffer holds.
Reproduce
git checkout main
npm run deps:check
# exit 1, lists the 5 deps above
Related
Symptom
npm run deps:checkexits 1 on main with 5 cargo deps newer than the 7-day threshold:Same Cargo.lock entries on main fail the same gate (verified locally on the unchanged main checkout, see PR #222 follow-up note).
Impact
The
deps-ageGitHub Actions job runsnpm run deps:checkwhenever any npm file changes. With these versions, the gate stays red until either:Until then, any PR touching
package.jsonorpackage-lock.jsonis blocked. PR #222 had to dodge this by structuring its changes carefully; this will bite future PR work.Why is this happening?
Likely caused by a Dependabot group bump (e.g.
#205whichfix(deps): resolve 9 of 28 cargo-audit advisories) that landed these crate versions very recently. The 7-dayMIN_AGE_DAYSgate is enforced uniformly across all deps; transitives on the lockfile get checked via the resolved-version lookup inscripts/check-deps.mjs.Possible fixes
scheduleconfig.KNOWN_ACCEPTEDarray inscripts/cargo-audit-check.sh.Suggested approach
Option 1 + Option 2 combined: let these clear naturally, then add a Dependabot schedule that spreads out major-version group bumps so the 7-day buffer holds.
Reproduce
git checkout main npm run deps:check # exit 1, lists the 5 deps aboveRelated
scripts/check-deps.mjsis the check..github/workflows/ci.ymldeps-agejob runs it on PRs touchingpackage*.json.