Repository navigation
bug: a pulled turn's system prompt states the recorded timeout, not the clamped limit it actually runs under #3321
Description
Summary
services/pull_coordination_service.py::_build_claim_response builds the platform prompt from the queued row's recorded timeout_seconds. claim_next_task only clamps the turn limit to the agent's timeout (#2846) afterwards. So the model is told "Timeout: 1800s — plan to finish well within this budget" but is killed at 600s.
Repro: agent timeout 600, queued row metadata {"timeout_seconds": 1800}, then claim the row.
Context
An operator can lower the agent's timeout while rows are queued (routers/agent_config.py). This breaks the #3114 parity contract, under which the prompt states the timeout the turn actually runs under. Found by the 2026-10-06 /edge-cases sweep.
Acceptance Criteria
- The timeout in the prompt equals the enforced turn limit.
-
tests/unit/test_ec_pull_coordination_edges.py::TestTurnLimit::test_T14_prompt_timeout_equals_the_enforced_limitpasses with its marker removed.
Activity
fix(pull): clamp the turn limit before composing the pulled prompt (#…
vybe commentedon Oct 9, 2026
Draft PR: #3419 — the pulled prompt states the enforced timeout; reading review MERGEABLE, evidence sweep green. Waits for CI and the operator's merge. (trinity-pm, build-chain run chain-easy-1008)
docs(pull): claim_next_task docstring names where the clamp now lives (…
fix(pull): a pulled turn's prompt states the timeout it actually runs…