refactor: bind cron jobs to origin sessions

This commit is contained in:
chengyongru
2026-06-12 14:00:53 +08:00
parent 271b3651d7
commit 80524e9e88
14 changed files with 47 additions and 267 deletions
+11 -8
View File
@@ -213,20 +213,23 @@ Rules:
session being deleted.
- Do not block on system jobs.
- Do not block on legacy unbound jobs.
- In unified-session mode, WebUI chats display cron jobs owned by
`unified:default`, but deleting an individual `websocket:*` thread should not
block on or delete those unified cron jobs.
- In unified-session mode, WebUI-created cron jobs still belong to the concrete
`websocket:*` chat that created them, so deleting that chat should block on or
delete those jobs.
- If the user manually deletes files outside the WebUI/API, do not try to
compensate.
## Unified Session Mode
When `unified_session` is enabled, WebUI-created cron jobs should bind to the
same unified session as normal WebUI chat turns: `unified:default`.
When `unified_session` is enabled, WebUI-created cron jobs should still bind to
the concrete WebUI chat that created them, for example `websocket:<chat_id>`.
The cron trigger is delivered through that original chat. `AgentLoop` then
applies `unified_session` normally, so the turn's memory/session context may be
`unified:default` even though the cron job's ownership key is concrete.
- All WebUI chats should display cron jobs owned by `unified:default`.
- Individual WebUI thread deletion should remain scoped to the concrete
`websocket:*` thread being deleted.
- Each WebUI chat should display cron jobs owned by that concrete chat.
- Individual WebUI thread deletion should block on cron jobs owned by that
concrete `websocket:*` thread.
- Toggling `unified_session` does not migrate existing cron jobs. Existing jobs
keep their stored `payload.session_key` and continue to execute against that
owner until explicitly removed or recreated.