fix: P0 cron delivery threading + suppress no-change progress checks#36
fix: P0 cron delivery threading + suppress no-change progress checks#36dgarson merged 2 commits intodgarson/forkfrom
Conversation
…ersations Cron announce deliveries now strip session-derived threadIds by default. This prevents cron output from landing inside whatever Slack/Discord thread was last active in the agent's main session — a race condition that caused misrouted messages when cron jobs finished while a human conversation was active in the same channel. Only explicitly-configured threadIds (e.g. Telegram :topic: syntax in delivery.to) are preserved. Session-inherited threadIds from the agent's lastThreadId are no longer carried through to cron delivery targets. Changes: - delivery-target.ts: Add stripSessionThreadId parameter that, when set, drops session-derived threadIds while preserving explicit ones - run.ts: Set stripSessionThreadId=true for all cron announce deliveries - Added 3 new tests covering the stripping behavior Fixes: misrouted Luis UX status update threading into David's instruction thread in #cb-inbox (2026-02-21 13:14 MST incident) Ref: /Users/openclaw/.openclaw/workspace/xavier/root-cause-dropped-task-2026-02-21.md
…rsations When a cron job finishes and delivers its output via the subagent announce flow, the delivery target resolution correctly strips session-derived threadIds via stripSessionThreadId. However, resolveAnnounceOrigin() in the announce flow was merging the stripped origin with the session entry's delivery context, re-introducing the stale threadId from whatever Slack thread was last active in the main session. This caused cron announce messages (e.g. Luis UX Work Check) to land inside unrelated threads (e.g. David's instruction thread) when the main session had recently interacted with that thread. Fix: when requesterOrigin provides a full delivery target (channel + to) but intentionally omits threadId, do not fall back to the session entry's threadId. Strip it from the fallback context before merging. Root cause: #cb-inbox incident 2026-02-21 — Luis cron output threaded into David's instruction, causing the instruction to appear handled when it was actually dropped. Ref: /Users/openclaw/.openclaw/workspace/xavier/root-cause-dropped-task-2026-02-21.md
|
Tim review (P0) complete. ✅ I validated the thread-routing fix path end-to-end in the local worktree:
✅ Targeted tests run: Assessment: logic is correct and narrowly scoped for the incident class (session-derived stale thread IDs reintroduced during cron announce path). |
|
Starting review — Tim |
|
Review complete — the fix is sound and directly addresses the stale threadId incident path. Given this is P0 behavior and targets , I recommend landing this directly rather than waiting for a mega-branch. @xavier can you confirm if you want this to stay on as-is? — Tim |
|
Follow-up clarification: recommendation is to land this directly to main (not a separate mega-branch), given P0 impact. — Tim |
KnowledgeBase: doc library with markdown render, master/detail, 8 seed docs CrashReporter: crash event log with stack traces, 8 reports, filter chips Sprint total: 37 views
Summary
Three P0 fixes from root cause analysis of dropped instructions:
Files Changed
3 new tests, 326 related tests pass.
Priority: P0 | Author: xavier