← Back to PRs

#6315: fix(cron): persist isolated sessions (fixes #6217) - attempt 2

by ChaitanyaSai-Meka open 2026-02-01 14:38 View on GitHub →
## Fix: Cron Jobs with Isolated Sessions Not Delivering Messages > **Note to Maintainers:** This is a re-submission of PR #6238 which was auto-closed by Clawdinator. > This PR fixes a confirmed bug discussed in Issue #6217. Please do not auto-close. ### Linked Context * **Fixes #6217** (The original bug report) * **Replaces #6238** (The previous PR closed by bot) ### Root Cause The `resolveCronSession` function in `src/cron/isolated-agent/session.ts` created sessions in memory but never persisted them to the store. This caused silent failures in isolated cron jobs. ### Changes Made 1. **Persistence:** Updated `resolveCronSession` to strictly await `updateSessionStore` before returning. 2. **Async Handling:** Updated `run.ts` to await the session resolution. ### Testing Validated with reproduction payload from #6217. Messages are now delivered and sessions appear in `sessions_list`. <!-- greptile_comment --> <h2>Greptile Overview</h2> <h3>Greptile Summary</h3> This PR fixes isolated cron sessions not being persisted by (1) making `resolveCronSession` async and writing the computed `SessionEntry` into the session store, and (2) awaiting `resolveCronSession` from the isolated cron runner. The change aligns cron session creation with the rest of the session-store machinery in `src/config/sessions/*` (notably `updateSessionStore`’s lock + read-modify-write semantics), so newly created isolated sessions show up in `sessions_list` and downstream code (skills snapshot updates, systemSent persistence, usage/model updates) can safely assume a persisted session exists. <h3>Confidence Score: 4/5</h3> - This PR is likely safe to merge and addresses the reported persistence bug, with a small risk around error propagation in `resolveCronSession`. - The behavior change is narrow (awaiting session resolution + persisting a session entry). The main concern is that `sessionEntry` is assigned inside the `updateSessionStore` callback and then non-null asserted; if the store update fails before the callback runs, the function can return an invalid value and mask the real error. Minor perf/format nits aside, the approach matches existing store update patterns. - src/cron/isolated-agent/session.ts <!-- greptile_other_comments_section --> <sub>(3/5) Reply to the agent's comments like "Can you suggest a fix for this @greptileai?" or ask follow-up questions!</sub> **Context used:** - Context from `dashboard` - CLAUDE.md ([source](https://app.greptile.com/review/custom-context?memory=fd949e91-5c3a-4ab5-90a1-cbe184fd6ce8)) - Context from `dashboard` - AGENTS.md ([source](https://app.greptile.com/review/custom-context?memory=0d0c8278-ef8e-4d6c-ab21-f5527e322f13)) <!-- /greptile_comment -->

Most Similar PRs