chore(deps): upgrade rq to 2.11

[sdornan]

Description

uv.lock sat on rq 2.9.0 while pyproject.toml allowed anything under 3.0, so the floor now names the version the code is actually tested against.

2.11 is the release the scheduler work ahead needs:

• RQScheduler acquires and refreshes its lock before enqueueing, which matters as soon as delayed jobs are released by a worker rather than a separate process.
• Each CronJob has a name and keeps the ids of the jobs it created (cron_job.get_job_ids()) — the introspection a move to rq cron would otherwise cost, since cron state stops living in Redis.
• Calling create_cron() more than once no longer duplicates jobs.

2.10 also added webhook notifications and a stable scheduler identity, and 2.9.1 covers redis-py >= 8.

The constraint stays under 3.0 deliberately: that release moves get_current_job() to contextvars, reworks dependency handling behind a ReadyJobRegistry, and changes the Worker.handle_job_success() signature, which RomMWorker subclasses around.

Note on the quarantine window

2.11.0 was published on 2026-08-17, so it is still inside the rolling 7-day exclude-newer window and needs a per-package exclusion to resolve today. The window reaches it on 2026-08-24, after which the entry can be deleted and the constraint resolves on its own — happy to drop the override and let it land that way instead, if you would rather not bypass the window at all.

Checklist

• I've tested the changes locally
• I've updated relevant comments
• I've assigned reviewers for this PR
• I've added unit tests that cover the changes

^{No tests added: this is a dependency bump with no behaviour change of its own.}

Testing

Full backend suite green (3003 passed, 2 skipped), trunk fmt && trunk check clean, and the lockfile diff touches nothing but rq.

Also verified against a real Redis, since the suite's coverage of the scheduler is mostly mocked. Every rq internal the rq-scheduler fork reaches into still exists in 2.11 (rq.utils.backend_class, rq.utils.import_attribute, rq.logutils.ColorizingStreamHandler, Queue.from_queue_key, Queue.enqueue_job, job.enqueue_at_front), and each scheduler API RomM uses still behaves: enqueue_in and cron produce SCHEDULED jobs with the expected func_name, get_jobs(with_times=True) returns due times, a past-due job is queued by enqueue_jobs(), and cancel() clears the registry entry.

One thing that surfaced while testing, unrelated to this bump: rq-scheduler calls crontab.CronTab.next() without default_utc, which now emits a FutureWarning about the coming utcnow() change in crontab 0.22+.

AI assistance disclosure

This change was written with AI assistance (Claude Opus 5 via Claude Code). The changelog review, the compatibility checks, and this description were AI-generated, then verified by me against the rq sources and a local run of the suite plus the real-Redis checks described above.

[socket-security]

Review the following changes in direct dependencies. Learn more about Socket for GitHub.

Diff	Package	Supply Chain Security	Vulnerability	Quality	Maintenance	License
	pypi/​rq@​2.9.0 ⏵ 2.11.0

View full report

[greptile-apps]

Greptile Summary

Raises the supported and locked RQ version from 2.9.0 to 2.11.0 in preparation for scheduler work.

• Updates the direct RQ constraint to ~=2.11.
• Regenerates the lock entry with RQ 2.11.0 artifacts and hashes.
• Adds a temporary package-specific freshness-window exemption for the newly released version.

Confidence Score: 5/5

The PR appears safe to merge, with no actionable changed-code defect identified.

The manifest and lockfile consistently select RQ 2.11.0, and the dependency advisories present in the lockfile are pre-existing and not made reachable or worse by this upgrade.

Important Files Changed

Filename	Overview
pyproject.toml	Updates the RQ constraint and adds a documented temporary resolution-window exemption; no actionable defect was identified.
uv.lock	Locks RQ 2.11.0 without changing its resolved transitive dependencies; no changed-code-connected advisory or compatibility defect was established.

_{Reviews (1): Last reviewed commit: "chore(deps): upgrade rq to 2.11" | Re-trigger Greptile}

[Copilot]

Pull request overview

Updates the backend job-queue dependency baseline by bumping rq to 2.11.x and aligning the lockfile accordingly, including a temporary exclude-newer override so the resolver can pick up 2.11.0 within the 7-day window.

Changes:

• Bump rq dependency constraint from ~=2.7 to ~=2.11.
• Update uv.lock to rq==2.11.0 and reflect the new specifier in the resolved dependency set.
• Add a temporary per-package exclude-newer-package entry for rq (mirroring the existing vcrpy approach) to allow resolving the new release before the rolling window elapses.

Reviewed changes

Copilot reviewed 1 out of 2 changed files in this pull request and generated no comments.

File	Description
pyproject.toml	Raises the rq version floor to ~=2.11 and adds a temporary exclude-newer-package override for rq.
uv.lock	Locks rq to 2.11.0 and records the per-package exclude-newer override timestamp used by uv during resolution.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[sdornan]

Folded into #4274, which is now the only consumer of the bump.

Correcting the claim in the description while I am here: the scheduler migration does not need 2.11. Every API it uses exists in 2.9.0, which was already locked. 2.11 is what it benefits from — the scheduler refreshing its lock before enqueueing, which matters once a worker rather than a separate process releases delayed jobs, and CronJob names and job history, which is the introspection that moving cron out of Redis would otherwise cost.

The exclude-newer-package entry for rq carries over to #4274 and is deletable from 2026-08-24, when the rolling window reaches 2.11.0.