[P1] Scheduled tasks must start fresh run contexts seeded by the previous terminal output #110

New issue

Closed

opened 2026-09-06 04:30:55 +00:00 by nsaspy · 0 comments

nsaspy commented

2026-09-06 04:30:55 +00:00

Owner

Summary

Every scheduled task occurrence must start in a fresh AgentContext. It must not reuse the full chat/model/tool history from earlier occurrences.

The only state carried into the next occurrence should be the previous run's validated terminal output, supplied explicitly as bounded input alongside the current task prompt.

This is a separate lifecycle contract from #107 (wrong history truncation) and #108 (deadlines and terminal-result validation).

Current behavior

helpers/task_scheduler.py:

lines 826-838 create an AgentContext using task.context_id.
lines 840-858 return an existing AgentContext whenever that context ID is already registered.
lines 900-907 select the reused context's existing agent.
lines 932-953 append another task prompt to that same accumulated history.
lines 860-863 require the persisted chat ID to remain equal to task.context_id.

Because context_id normally equals the durable task UUID, every scheduled occurrence inherits all previous model messages, tool outputs, response IDs, temporary loop state, and context growth.

The live hackmode-rage-worker reached 702 history messages, 342 iterations, 341 provider response IDs, and only 7 response-tool completions. Reusing that history also exposed the oldest-first truncation in #107.

Required behavior

Keep durable task identity separate from per-occurrence run identity:

Each occurrence gets a unique run_id and a new AgentContext/run context.
Initialize it only with:
- the task system prompt,
- the current task prompt,
- a structured Previous run result section containing the immediately preceding validated terminal output, if one exists,
- explicitly configured attachments/project context.
Do not inherit prior History objects, provider response IDs, pending tool-call state, temporary loop parameters, subagent state, or active transport state.
Persist the run context as an independently inspectable chat and link it back to the durable task UUID.
After successful terminal completion, atomically promote that output to previous_run_output for the next occurrence.
Failed, cancelled, timed-out, empty, or raw tool-call results must not replace the last known successful terminal output. Their structured status may be supplied separately if desired.
Bound the carried output by an explicit byte/token policy, preserving a digest and link to the full prior run when truncated.

Acceptance criteria

Two successive occurrences of one scheduled task have distinct AgentContext IDs and clean provider/tool state.
Run N+1 receives exactly run N's validated terminal output as explicit input.
Run N+1 does not receive run N-1 history or any other old messages.
A failed run between two successful runs does not poison or erase the last successful output.
Concurrent/manual retries use unique run IDs and idempotent result promotion so an older completion cannot overwrite a newer run.
Scheduler APIs/UI expose durable task ID, current/last run ID, last successful output, and last run status separately.
Existing scheduled tasks migrate without deleting their historical chats.
Tests cover first run, consecutive success, failure, timeout, cancellation, restart recovery, output truncation, and concurrent completion ordering.
Integrate with #108 so only terminal response-tool completion can become previous_run_output.
Integrate with #107 so normal chat recency logic is not used as a substitute for this explicit handoff contract.

## Summary Every scheduled task occurrence must start in a fresh AgentContext. It must not reuse the full chat/model/tool history from earlier occurrences. The only state carried into the next occurrence should be the previous run's validated terminal output, supplied explicitly as bounded input alongside the current task prompt. This is a separate lifecycle contract from #107 (wrong history truncation) and #108 (deadlines and terminal-result validation). ## Current behavior helpers/task_scheduler.py: - lines 826-838 create an AgentContext using task.context_id. - lines 840-858 return an existing AgentContext whenever that context ID is already registered. - lines 900-907 select the reused context's existing agent. - lines 932-953 append another task prompt to that same accumulated history. - lines 860-863 require the persisted chat ID to remain equal to task.context_id. Because context_id normally equals the durable task UUID, every scheduled occurrence inherits all previous model messages, tool outputs, response IDs, temporary loop state, and context growth. The live hackmode-rage-worker reached 702 history messages, 342 iterations, 341 provider response IDs, and only 7 response-tool completions. Reusing that history also exposed the oldest-first truncation in #107. ## Required behavior Keep durable task identity separate from per-occurrence run identity: 1. Each occurrence gets a unique run_id and a new AgentContext/run context. 2. Initialize it only with: - the task system prompt, - the current task prompt, - a structured Previous run result section containing the immediately preceding validated terminal output, if one exists, - explicitly configured attachments/project context. 3. Do not inherit prior History objects, provider response IDs, pending tool-call state, temporary loop parameters, subagent state, or active transport state. 4. Persist the run context as an independently inspectable chat and link it back to the durable task UUID. 5. After successful terminal completion, atomically promote that output to previous_run_output for the next occurrence. 6. Failed, cancelled, timed-out, empty, or raw tool-call results must not replace the last known successful terminal output. Their structured status may be supplied separately if desired. 7. Bound the carried output by an explicit byte/token policy, preserving a digest and link to the full prior run when truncated. ## Acceptance criteria - Two successive occurrences of one scheduled task have distinct AgentContext IDs and clean provider/tool state. - Run N+1 receives exactly run N's validated terminal output as explicit input. - Run N+1 does not receive run N-1 history or any other old messages. - A failed run between two successful runs does not poison or erase the last successful output. - Concurrent/manual retries use unique run IDs and idempotent result promotion so an older completion cannot overwrite a newer run. - Scheduler APIs/UI expose durable task ID, current/last run ID, last successful output, and last run status separately. - Existing scheduled tasks migrate without deleting their historical chats. - Tests cover first run, consecutive success, failure, timeout, cancellation, restart recovery, output truncation, and concurrent completion ordering. - Integrate with #108 so only terminal response-tool completion can become previous_run_output. - Integrate with #107 so normal chat recency logic is not used as a substitute for this explicit handoff contract.

nsaspy added the

bug

label

2026-09-06 04:30:55 +00:00

nsaspy referenced this issue from a pull request that will close it,

2026-09-06 04:59:05 +00:00

fix: isolate scheduled task run contexts #111

nsaspy closed this issue

2026-09-06 05:15:57 +00:00