Summary
Fixes #4082 — cron jobs reused the same session key for every run, so later executions could see stale context from earlier runs.
Change
In nanobot/cron/bound_runner.py, append the unique run_id to the session key override so each cron run gets an isolated session.
Verification
ruff check— cleanpytest tests/cron/— 89 passed
Activity
7
dajiaohuang4mo agoThanks for the review! Addressed the session proliferation concern:
Each per-run cron session (:job_id:timestamp:uuid) is now deleted after the turn completes (both success and error paths). Added delete_session() to the BoundCronAgent protocol and AgentLoop so storage stays bounded regardless of cron frequency.
Re: loss of cross-run continuity — for stateless jobs (reminders, reports) this is the desired behavior. For monitoring/diff-detection jobs that genuinely need cross-run context, a future shared_session option could be added, but that's a design decision for maintainers.
dajiaohuang4mo agoThanks for the review! Addressed the session proliferation concern:
Each per-run cron session (:job_id:timestamp:uuid) is now deleted after the turn completes (both success and error paths). Added delete_session() to the BoundCronAgent protocol and AgentLoop so storage stays bounded regardless of cron frequency.
Re: loss of cross-run continuity — for stateless jobs (reminders, reports) this is the desired behavior. For monitoring/diff-detection jobs that genuinely need cross-run context, a future shared_session option could be added, but that's a design decision for maintainers.
dajiaohuang4mo agoThanks for the review! Addressed the session proliferation concern:
Each per-run cron session (:job_id:timestamp:uuid) is now deleted after the turn completes (both success and error paths). Added delete_session() to the BoundCronAgent protocol and AgentLoop so storage stays bounded regardless of cron frequency.
Re: loss of cross-run continuity — for stateless jobs (reminders, reports) this is the desired behavior. For monitoring/diff-detection jobs that genuinely need cross-run context, a future shared_session option could be added, but that's a design decision for maintainers.
Automated PR review by nanobot. This is not a human maintainer review or approval.
This PR isolates each cron run into its own session by appending
:{run_id}to the session key, preventing later runs from seeing stale context from previous runs.Side effects to consider
Session proliferation: Every cron run now creates a distinct session entry (e.g.
myjob:job1:1234567890:abc123). For a job running every 2 hours that's ~12 sessions/day with no cleanup mechanism. Over weeks this accumulates unbounded session storage. Heartbeat hasretain_recent_legal_suffixto bound its history; cron sessions have no equivalent.Loss of cross-run continuity: Previously, repeated cron runs shared a session, so the agent could reference context from prior runs (e.g. "this issue was already reported last time"). With per-run isolation, each invocation starts with a blank slate. Whether this is desirable depends on the use case — for stateless reminders it's fine, but for monitoring/diff-detection jobs it removes useful context.