#6315: fix(cron): persist isolated sessions (fixes #6217) - attempt 2
Cluster:
Cron Job Enhancements
## 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
#23501: fix(cron): force new session ID for isolated cron jobs (#23470)
by stakeswky · 2026-02-22
86.6%
#23699: fix(cron): isolated sessions must generate fresh UUID on every run ...
by echoVic · 2026-02-22
84.7%
#20188: fix: Update sessionFile path when rolling to new session in cron jobs
by jriff · 2026-02-18
84.6%
#23562: feat: add sessionFreshness config for isolated cron jobs (#23539)
by MunemHashmi · 2026-02-22
82.8%
#15294: fix(cron): reset token counters when creating new isolated session
by Elarwei001 · 2026-02-13
81.7%
#23086: fix(cron): surface channel resolution error for isolated sessions w...
by hydro13 · 2026-02-22
79.9%
#19385: fix: pass authProfileId from cron session to runEmbeddedPiAgent
by gigi-trifle · 2026-02-17
79.1%
#6653: fix: persist archived session entry on /new or /reset
by leicao-me · 2026-02-01
78.7%
#16390: fix(cron): jobs land in wrong agent session when agentId isn't in a...
by yinghaosang · 2026-02-14
78.6%
#11474: fix(cron): respect subagents.model in isolated cron sessions
by AnonO6 · 2026-02-07
78.5%