fix(amazonq): narrow tool-use truncation detection and classify retries in telemetry

[laileni-aws]

Issue

Three related problems in how the agentic chat loop handles a response stream that ends without a terminating tool-use stop event.

1. Truncation detection was too broad. Every such stream was treated as a truncated tool input. But a stream also ends without stop when:

• the request was aborted — response-processing timeout, or user cancellation — where the missing stop is expected and the abort is already reported by its own path; and
• the model announced a tool use but streamed no input at all, so there is nothing to truncate and nothing to retry.

Reporting those as failures and re-prompting the model produces failed intermediate stream events for turns that were never broken, and can re-run the agent loop without making progress.

2. Retries were unbounded. The incomplete-tool-use retry path had no iteration limit, so repeated truncation could keep the loop running indefinitely.

3. The telemetry could not distinguish the cases. Every retried iteration emits amazonq_invokeLLM with result='Failed', with nothing to separate a transient iteration that recovers inside the same user turn from a terminal failure the user actually sees. Any per-call success rate built on that metric therefore degrades precisely when error handling becomes more honest, even though users are unaffected.

Changes

finalize() only reports genuine truncation. It now requires that partial input was actually received and that the request was not aborted. Other unterminated tool uses are left unstopped and filtered out downstream, exactly as they were before this behaviour was introduced. The abort state is passed into finalize() from the response processor.

Retries are bounded. MAX_INCOMPLETE_TOOL_USE_RETRIES = 3, so at most 4 attempts in total. On exceeding the limit the loop stops and surfaces an actionable error to the user instead of retrying indefinitely.

Failures are classified for telemetry. amazonq_invokeLLM now carries a reason alongside the existing result:

reason	meaning
INCOMPLETE_TOOL_USE_RETRYING	retry budget remains; transient, normally recovers in the same turn
INCOMPLETE_TOOL_USE_EXHAUSTED	retries used up; the user sees an error

result stays 'Failed' in both cases, so raw failure counts are unchanged and remain available for diagnostics. Downstream consumers can exclude the transient class from per-call success rates while still counting the terminal give-up.

The classification is computed before the emit. Because the retry budget is bounded, whether an iteration will be retried is already known at that point, so no post-hoc correlation is needed.

Genuine truncation still routes into the existing recovery path and is retried.

Why two reason values rather than one truncation flag

Excluding all truncation from a success rate would also hide the case where the agent retries, exhausts its budget and gives up — which the user does experience as an error. Keeping the terminal case distinct avoids trading one blind spot for another, which is the mistake that motivated this change in the first place.

Compatibility

reason is a new optional field and result semantics are unchanged, so existing consumers are unaffected. The two string values are read by the downstream telemetry transform to emit a separate counter, so renaming either requires updating that transform first — noted in a comment on the constants.

Retry behaviour is unchanged by the telemetry commit: incrementing the counter before the emit and testing count <= MAX_INCOMPLETE_TOOL_USE_RETRIES preserves the existing off-by-one.

Testing

• agenticChatEventParser.test.ts — 10/10 pass, including new cases for the aborted path and the zero-input path.
• chatTelemetryController.test.ts — 20/20 pass, including 3 new cases covering reason forwarding, the retrying/exhausted distinction, and that result stays 'Failed'.
• tsc --noEmit clean for all changed files.

Not covered: no end-to-end agent-loop test asserts the RETRYING to EXHAUSTED transition at the retry-limit boundary. The existing controller test harness stubs the streaming client and could support one — happy to add it if reviewers want that boundary locked down.