chore(deps)!: 7-day dependency cooldown (uv exclude-newer + CI assert)#788
chore(deps)!: 7-day dependency cooldown (uv exclude-newer + CI assert)#788xdotli wants to merge 16 commits into
Conversation
… hard rule Never resolve a dependency to a release younger than ~7 days (less-vetted; the freshly-published-CVE churn during #787 is the motivating case). Enforced two ways: - `[tool.uv] exclude-newer` caps every `uv lock` at a fixed timestamp (currently 2026-06-08, >=7 days ago); advance it (kept >=7d in the past) to take updates. - `tests/test_dep_cooldown.py` fails CI if `exclude-newer` is ever within the last 7 days, so the cap can't silently drift forward. Grandfather overrides in `[tool.uv.exclude-newer-package]` for deps the repo already pins that are still <7d old (each should be removed as it ages past 7d): - litellm[proxy]==1.89.0 (2026-06-13) — exact pin; blocks resolution otherwise. - starlette 1.3.1 (2026-06-12) — CVE-2026-54282/54283 fix; don't roll back to the vulnerable 1.2.1. Security exception is the override mechanism: an urgent fix younger than the cap is allowed via a commented per-package entry. Re-locking under the cap rolled 6 langchain-family packages back by a patch/minor (their newest releases are <7d old); full suite green (4190).
xdotli
temporarily deployed
to
pypi-internal-preview
GitHub Actions
Inactive
Greptile SummaryThis PR introduces a hard 7-day dependency cooldown enforced at two layers: a static
Confidence Score: 5/5Safe to merge. The cooldown enforcement is self-consistent across both layers, all previous findings have been addressed, and the The two-layer enforcement is logically coherent: the static cap and the dynamic lock audit use the same The Important Files Changed
Reviews (6): Last reviewed commit: "Fix dependency cooldown override expiry" | Re-trigger Greptile |
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
| def test_uv_exclude_newer_enforces_dependency_cooldown() -> None: | ||
| cfg = tomllib.loads(_PYPROJECT.read_text(encoding="utf-8")) | ||
| raw = cfg.get("tool", {}).get("uv", {}).get("exclude-newer") | ||
| assert raw, ( | ||
| "[tool.uv] exclude-newer is missing from pyproject.toml — it enforces the " | ||
| f"{COOLDOWN_DAYS}-day dependency cooldown and must be set." | ||
| ) | ||
| cutoff = datetime.datetime.fromisoformat(str(raw).replace("Z", "+00:00")) | ||
| if cutoff.tzinfo is None: | ||
| cutoff = cutoff.replace(tzinfo=datetime.UTC) | ||
| age = datetime.datetime.now(datetime.UTC) - cutoff | ||
| assert age >= datetime.timedelta(days=COOLDOWN_DAYS), ( | ||
| f"[tool.uv] exclude-newer ({raw}) is only {age.days}d old; the dependency " | ||
| f"cooldown requires it to be >= {COOLDOWN_DAYS} days in the past. Bump it " | ||
| f"to an older date (>= {COOLDOWN_DAYS}d ago) when taking dependency updates." | ||
| ) |
There was a problem hiding this comment.
The test guards [tool.uv] exclude-newer but never inspects [tool.uv.exclude-newer-package]. The per-package overrides are the one channel through which a package newer than the global cooldown can enter the lockfile, yet nothing checks that those entries carry a required comment, or that they're removed once the package crosses the 7-day mark. In practice the litellm and starlette entries will silently linger forever after they age out, and a future engineer can add another entry without any guardrail. Adding a second assertion that iterates cfg["tool"]["uv"].get("exclude-newer-package", {}) and verifies each override timestamp is still within some reasonable tolerance (e.g., entry date ≥ global exclude-newer date) would close this gap without much code.
There was a problem hiding this comment.
Fixed in 151c63d7 on the pushed head 44133f5c. The original expiry side was already covered; this now also enforces the rationale side without relying on TOML comments. Each [tool.uv.exclude-newer-package] entry must have a matching non-empty [tool.benchflow.dependency-cooldown.override-rationale] entry, and stale rationale entries without an override fail too. Validation passed locally: tests/test_dep_cooldown.py tests/test_lock_tool.py (24 passed), uv lock --check, tools/lock.py --check -> 2026-06-26T00:00:00Z, ruff, ty, format check. GitHub CI is still running on the new head.
| assert age >= datetime.timedelta(days=COOLDOWN_DAYS), ( | ||
| f"[tool.uv] exclude-newer ({raw}) is only {age.days}d old; the dependency " | ||
| f"cooldown requires it to be >= {COOLDOWN_DAYS} days in the past. Bump it " | ||
| f"to an older date (>= {COOLDOWN_DAYS}d ago) when taking dependency updates." | ||
| ) |
There was a problem hiding this comment.
age.days, which is the integer days component of the timedelta, not the total elapsed days rounded. For a gap like 6 days 23 h 50 min, it prints "6d old" while the assertion correctly sees it as still less than 7 days — the diagnostic makes the boundary look farther away than it is. Prefer age.total_seconds() / 86400 for accurate sub-day precision.
| assert age >= datetime.timedelta(days=COOLDOWN_DAYS), ( | |
| f"[tool.uv] exclude-newer ({raw}) is only {age.days}d old; the dependency " | |
| f"cooldown requires it to be >= {COOLDOWN_DAYS} days in the past. Bump it " | |
| f"to an older date (>= {COOLDOWN_DAYS}d ago) when taking dependency updates." | |
| ) | |
| assert age >= datetime.timedelta(days=COOLDOWN_DAYS), ( | |
| f"[tool.uv] exclude-newer ({raw}) is only {age.total_seconds() / 86400:.1f}d old; " | |
| f"the dependency cooldown requires it to be >= {COOLDOWN_DAYS} days in the past. " | |
| f"Bump it to an older date (>= {COOLDOWN_DAYS}d ago) when taking dependency updates." | |
| ) |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: edfa207867
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| # comment recording why. Remove the override once the package is >= 7 days old. | ||
| exclude-newer = "2026-06-08T00:00:00Z" | ||
|
|
||
| [tool.uv.exclude-newer-package] |
There was a problem hiding this comment.
In environments that still have uv 0.7.x, this new table is an unknown [tool.uv] key: uv sync --locked reports unknown field exclude-newer-package, ignores the lockfile cutoff as removed, and tries to re-resolve from PyPI instead of installing the committed lock. Since the repo only requires users to have uv and does not set tool.uv.required-version, local setup and any older CI image can fail or bypass the intended cooldown; pin/install a uv version that supports per-package cutoffs before relying on this syntax.
Useful? React with 👍 / 👎.
The 7-day cooldown date in [tool.uv] exclude-newer was hand-typed. Add tools/lock.py to compute it as midnight-UTC of (today - 7d) and re-lock in one step, so the date is set dynamically instead of guessed. The committed value stays static (CI's uv sync --locked must be deterministic against the lock); the helper just rolls it forward to the newest still-vetted day. - tools/lock.py: compute_cooldown_cutoff + rewrite_exclude_newer + CLI (--check / --no-lock); single COOLDOWN_DAYS source imported by the gate. - tests/test_lock_tool.py: unit tests for the date/text transforms. - test_dep_cooldown.py: import COOLDOWN_DAYS from tools.lock (no drift). - pyproject/AGENTS.md: point contributors at the helper, not hand-edits.
xdotli
temporarily deployed
to
pypi-internal-preview
GitHub Actions
Inactive
…times The cutoff date in [tool.uv] exclude-newer is inherently static (CI's uv sync --locked must match the lock), so trusting that date alone isn't a live '7 days ago from today' check. Add the dynamic half: read the upload-time uv bakes into uv.lock for every resolved package and fail if any is younger than now-7d, honoring documented [tool.uv.exclude-newer-package] exemptions. This evaluates the window against the current date on every CI run, stays offline (timestamps are in the lock — no PyPI queries), and never flakes on an unchanged lock (upload times are immutable, so packages only age out). - tools/lock.py: newest_upload_times + find_cooldown_violations. - test_dep_cooldown.py: split into caps-resolution (static cutoff >= 7d) + locked-packages-respect-cooldown (dynamic, the real invariant). - test_lock_tool.py: audit unit tests (latest-artifact, sourceless skip, exemptions, monotonic leniency over time).
xdotli
temporarily deployed
to
pypi-internal-preview
GitHub Actions
Inactive
| original = args.pyproject.read_text(encoding="utf-8") | ||
| updated = rewrite_exclude_newer(original, cutoff) | ||
| if updated != original: | ||
| args.pyproject.write_text(updated, encoding="utf-8") |
There was a problem hiding this comment.
OSError from file I/O is not caught. If args.pyproject doesn't exist (e.g., --pyproject wrong.toml) or lacks write permission, read_text() / write_text() raise FileNotFoundError / PermissionError, which fall outside the except LockError handler and produce a raw Python traceback. Catching OSError and converting it to LockError would give the same clean exit as every other failure path.
| original = args.pyproject.read_text(encoding="utf-8") | |
| updated = rewrite_exclude_newer(original, cutoff) | |
| if updated != original: | |
| args.pyproject.write_text(updated, encoding="utf-8") | |
| try: | |
| original = args.pyproject.read_text(encoding="utf-8") | |
| except OSError as exc: | |
| raise LockError(f"Cannot read {args.pyproject}: {exc}") from exc | |
| updated = rewrite_exclude_newer(original, cutoff) | |
| if updated != original: | |
| try: | |
| args.pyproject.write_text(updated, encoding="utf-8") | |
| except OSError as exc: | |
| raise LockError(f"Cannot write {args.pyproject}: {exc}") from exc |
bingran-you
added
enhancement
|
Automation triage (2026-06-16): CI is green ( |
|
Follow-up automation review (2026-06-16): holding this despite green CI. Two dependency-policy blockers need author follow-up before human review/merge:\n\n1. |
bingran-you
added
review:changes-requested
When this matters in practiceThe cooldown only changes your workflow when you're updating dependencies (adding one, bumping a version, or pulling in a CVE fix). At that point, re-lock with: python tools/lock.pyIt sets The guardrail holds even if someone doesn't know about the helper
Escape hatchA genuinely urgent fix that's <7 days old (e.g. an active CVE) goes through a commented TL;DR: update deps → run |
Addresses two dep-cooldown policy gaps: 1. `required-version = ">=0.8.4"` — the `[tool.uv.exclude-newer-package]` override table is only honored by uv >= 0.8.4. Without a floor an older uv would silently ignore it and resolve a different lock. 2. Add `tools` to the sdist `only-include` allowlist. The shipped `tests/test_dep_cooldown.py` does `from tools.lock import ...`, so the sdist must include `tools` or the suite fails to import from a source distribution. Verified `uv build --sdist` now ships `tools/lock.py`. uv lock --check clean; test_dep_cooldown.py passes (2).
bingran-you
temporarily deployed
to
pypi-internal-preview
GitHub Actions
Inactive
|
Automation (2026-06-16): addressed both policy blockers I raised earlier, pushed as
Verification: Still holding for a human approval before merge per repo policy (bot/self review insufficient for |
bingran-you
added
review:pending
bingran-you
added
review:changes-requested
|
Users Simulation automation review (2026-07-08): ready by simulation on head Evidence:
Thermo-nuclear review: no blocker. Labels: |
bingran-you
temporarily deployed
to
pypi-internal-preview
GitHub Actions
Inactive
bingran-you
added
the
status:in-progress
ChatGPT Codex Connector
|
Daily scan fix update (2026-07-09): pushed What changed:
Local validation on the PR branch:
GitHub checks are running on the new head; I moved this to |
|
Daily scan follow-up (2026-07-09): pushed What changed:
Validation on the pushed branch:
GitHub CI is running again on |
bingran-you
temporarily deployed
to
pypi-internal-preview
GitHub Actions
Inactive
|
Users Simulation automation review (2026-07-09): ready by simulation on current head Evidence:
Caveat: this run used Thermo-nuclear review: no blocker. The policy logic remains localized in Labels: moving |
bingran-you
added
status:ready
|
Users Simulation automation review (2026-07-10): ready by simulation on head Verified:
Thermo-nuclear review: no blocking structure issue. Keeping |
|
Users Simulation automation review (2026-07-11): ready by simulation on head Scope checked: 7-day dependency cooldown ( Evidence:
Artifact health:
Thermo review: no blocker. |
bingran-you
added
status:blocked
|
Daily scan hygiene (2026-07-13): live GitHub now reports this PR as Current state:
Next action: rebase/merge current |
|
Users Simulation automation review (2026-07-13): behavior-ready but merge-blocked on head Scope checked: dependency cooldown helper, Evidence:
Blocker:
Thermo-nuclear review: no blocker. |
bingran-you
temporarily deployed
to
pypi-internal-preview
GitHub Actions
Inactive
bingran-you
temporarily deployed
to
pypi-internal-preview
GitHub Actions
Inactive
bingran-you
temporarily deployed
to
pypi-internal-preview
GitHub Actions
Inactive
|
Users Simulation automation follow-up (2026-07-13): ready by simulation on current head What changed:
Validation:
Note: |
bingran-you
added
status:ready
|
Users Simulation automation review (2026-07-14): ready by simulation on current head Scope checked: dependency cooldown policy, lock tooling, Click 8.4 error wording compatibility, package/trace import tests, CLI/SDK regression risk, and current rollout artifact health. Evidence:
Thermo-nuclear review:
Cost caveat:
|
3 participants
What
Adds a hard 7-day dependency cooldown:
uvmay never resolve a dependency to a release younger than ~7 days old. Motivation — the freshly-published-CVE churn during #787 (advisories landing on day-0 releases); a cooldown gives new releases time to be vetted.How (two layers, both evaluated against today)
[tool.uv] exclude-newercaps everyuv lockat a timestamp so the default resolution can't reach a brand-new release. It has to be a static literal (CI'suv sync --locked/uv export --lockedmust match the lock deterministically — a live value in pyproject would break--locked). So the date isn't hand-typed:python tools/lock.pycomputes midnight-UTC ofnow − 7d, writes it, and re-locks in one step.tests/test_dep_cooldown.py::test_uv_exclude_newer_caps_resolutionfails if the committed cutoff is younger than 7 days.test_locked_packages_respect_cooldownreads theupload-timethat uv bakes intouv.lockfor every resolved package and fails if any is younger thannow − 7d. This is the genuinely live "7 days ago from the current date" check — evaluated every CI run against today, no stored date trusted and no PyPI queries (timestamps are already in the lock). It never flakes on an unchanged lock: upload times are immutable, so packages only age out of the window.COOLDOWN_DAYS = 7lives once intools/lock.pyand is imported by the gate, so the writer and the check can't drift.Security / grandfather exception
uvhas no rolling cooldown natively, so deps the repo already pins that are still <7 days old get a one-time override in[tool.uv.exclude-newer-package](also the escape hatch for an urgent CVE fix). Each entry is exempted from layer 2 and should be removed as it ages past 7d:litellm[proxy]==1.89.0(2026-06-13) — exact pin; resolution fails without it.starlette1.3.1 (2026-06-12) — the CVE-2026-54282/54283 fix; the override keeps it instead of rolling back to the vulnerable 1.2.1.Verified the audit has teeth: with exemptions removed it flags exactly
litellm 1.89.0andstarlette 1.3.1; with them, it's clean.Impact
Re-locking under the cap rolled 6 langchain-family packages back by a patch/minor (langchain, -anthropic, -core, -google-genai, -openai, langsmith) — their newest releases are <7d old. The CVE fixes from #787 (aiohttp 3.14.1, python-multipart 0.0.32, starlette 1.3.1) are preserved. Full suite 4202 passed; ruff/format/ty clean.
python tools/lock.py --checktoday prints the committed2026-06-08T00:00:00Z, so the lock is unchanged.Latest automation fix (2026-07-03)
Pushed through
44133f5cto clear the current Users Simulation blockers:151c63d7adds a machine-checkable rationale gate for[tool.uv.exclude-newer-package]entries using[tool.benchflow.dependency-cooldown.override-rationale]; this avoids brittle TOML comment parsing while enforcing the policy intent.44133f5cmerges currentorigin/main, resolves theuv.lockconflict, and refreshes the cooldown cutoff/lockfile withtools/lock.py(exclude-newer = "2026-06-26T00:00:00Z").Local validation on the merged head:
GitHub CI is running on the new head and should be green before moving this back to
status:ready.Latest automation fix (2026-07-13)
Pushed through
c2fe73120to clear the current Users Simulation blockers:origin/mainintochore/dep-cooldown-7d, resolving theuv.lockconflict caused by main's TRL-SFT extra.trlcooldown override because current main requirestrl>=1.8.0,<2andtrl 1.8.0is newer than the active global cutoff.click 8.4.2to clearPYSEC-2026-2132while staying within the cooldown policy.Validation:
GitHub checks on
c2fe73120are green:test,pip-audit,manifest-parity / parity,integration-light / rollout-smoke, and detect-scope all passed.Current-head
integration-light-jobsartifact validated healthy withbenchflow-experiment-review: 1/1 rollout healthy, reward 1.0, ACP + LLM trajectories and training-readyresults.jsonlpresent, 311,687 tokens, 16 tool calls, total timing 250.4s.cost_usd/price_sourceremain null for this GLM/user-endpoint smoke, matching the known shared accounting caveat rather than a dependency-cooldown regression.