Note: this is an in-house item already being handled by the maintainer - not open for contribution. Filed for tracking only. Touches the fix resolver / remediation behavior, which is kept in-house.
Summary
The cooldown-aware fix resolver (#871, #872) surfaces an advisory warning when a recommended fix version is newer than the project's configured release cooldown (npm min-release-age, pnpm minimumReleaseAge, yarn npmMinimalAgeGate). But it is advisory only: --fix (and the self-fix.yml auto-PR Action) still applies that version regardless.
That means auto-fix can adopt a just-published version - exactly the danger window a cooldown exists to avoid (a hijacked release that is live but not yet caught, e.g. the chalk/debug compromise). This issue makes fix mode cooldown-aware in behavior, not just in the warning.
Proposed behavior
- When the recommended fix version for a finding falls inside the configured cooldown window,
--fix should hold it back (not auto-apply it) and clearly report why - reusing the existing cooldown message. The finding stays unfixed so the developer can validate and decide.
self-fix.yml (the auto-PR Action) needs no workflow change - it inherits the CLI behavior, so its batched PR simply will not include cooldown-window bumps.- Covers npm/pnpm/yarn (the PMs the cooldown reader supports); Bun is not covered.
Open design questions
- Only-fix-is-fresh case: if the only known non-vulnerable version is inside the window, do we (a) hold it back and report "held by cooldown, validate manually" (recommended - matches the intent), or (b) apply it with a prominent warning? Lean (a).
- Opt-out: should there be an override (e.g.
--ignore-cooldown flag / Action input) for teams that want auto-fix to proceed regardless? Decide during implementation.
- Reporting: distinguish "held back by cooldown" from "no fix available" in the fix summary and exit reporting so it is not mistaken for an unfixable finding.
Related
Builds on the cooldown-aware fix resolver (#871, #872).
Summary
The cooldown-aware fix resolver (#871, #872) surfaces an advisory warning when a recommended fix version is newer than the project's configured release cooldown (npm
min-release-age, pnpmminimumReleaseAge, yarnnpmMinimalAgeGate). But it is advisory only:--fix(and theself-fix.ymlauto-PR Action) still applies that version regardless.That means auto-fix can adopt a just-published version - exactly the danger window a cooldown exists to avoid (a hijacked release that is live but not yet caught, e.g. the chalk/debug compromise). This issue makes fix mode cooldown-aware in behavior, not just in the warning.
Proposed behavior
--fixshould hold it back (not auto-apply it) and clearly report why - reusing the existing cooldown message. The finding stays unfixed so the developer can validate and decide.self-fix.yml(the auto-PR Action) needs no workflow change - it inherits the CLI behavior, so its batched PR simply will not include cooldown-window bumps.Open design questions
--ignore-cooldownflag / Action input) for teams that want auto-fix to proceed regardless? Decide during implementation.Related
Builds on the cooldown-aware fix resolver (#871, #872).