Repository navigation
Explain model output-limit failures without repeating research calls - #693
Conversation
|
Droid finished @magnus919's task —— View job No high-confidence actionable findings were identified in the changed code. 0 inline comments posted |
|
Independent review of The review checked the narrow length-response classification, sanitized bounded metadata, receipt persistence under the existing owner fence, receipt reuse without dispatch, preservation of unknown outcomes after a lost write, and error propagation through model review. The HTTP tests exercise the first three model-call positions and verify stable status after a fresh application and idempotent admission. This was a source review. Full CI remains required. The new test checks status and events; it does not add a separate webhook-specific assertion for this error shape. |
When a model explicitly reported that it had reached its output limit, research status still said the call outcome was unknown. The response had arrived, but the transport discarded that distinction before the worker could save it.
Research now retains a sanitized failure receipt for
finish_reason=lengthand reportsmodel_output_limit. Restarting reuses that receipt without another model call. Status explains that no report was published and includes only safe status, finish reason and token counts. Timeouts, disconnects and unrecognized responses keep their existing unknown-outcome behavior.Prompts, models, request limits, deadlines and retry behavior are unchanged. ADR-0075 and the user guide explain the failure and recovery contract.
Validation: the new regression failed before the fix; 62 focused transport, model-review and isolated-Valkey recovery tests pass. HTTP acceptance tests cover output-limit responses during planning, drafting and review, then verify status and idempotent admission after a fresh application without added calls. Full CI is required before merge.
Closes #692.