Merge main into feature/qdev-signup-block-delay - #2842
Open
aws-toolkit-automation wants to merge 7 commits into
Open
Merge main into feature/qdev-signup-block-delay#2842aws-toolkit-automation wants to merge 7 commits into
aws-toolkit-automation wants to merge 7 commits into
Conversation
…em silently (#2841) When a tool-use content block is streamed but the response ends before its terminating `stop` event (e.g. the output-token limit is reached mid tool-input), the tool-use input is never JSON-parsed and no error is recorded, so the parser reports success. The agentic loop keeps only stopped tool uses as pending, so the unterminated one is filtered out, the turn is reported as Succeeded, and the loop breaks -- the tool never runs and the user sees no error or retry. Add AgenticChatEventParser.finalize(), called once the response stream is fully consumed: any tool use still lacking a stop is marked stopped and given an incomplete-input error (reusing the malformed-JSON prefix) so it survives the pending-tool-use filter and is routed into the existing recovery path, which re-prompts the model to split the work into smaller tool uses. User cancellation is unaffected (aborts throw before finalize runs).
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
* fix: scope and forward stepId for the planning-branch lbv hitl The AWAITING_HUMAN_INPUT path already scopes the local-build-verification HITL to the loaded beamed repo and forwards its plan-step id, but the PLANNING branch did neither: it picked the first LBV HITL in the list and returned it without StepInformation. On a multi-repo beam where the job sits in PLANNING at build time, that surfaces a sibling's (or untagged) HITL, so the IDE scope guard cannot confirm ownership and defers the build indefinitely. Bring the PLANNING branch to parity with AWAITING_HUMAN_INPUT: - prefer the in-scope LBV via selectScopedLbvHitl (no-op when scope is empty, so non-beam behavior is unchanged) - forward StepInformation.StepId when present Verified live on a 3-repo beam: each loaded repo now builds and siblings are correctly deferred. * fix: suppress out-of-scope sibling LBVs in the planning branch Brings the PLANNING branch of getTransformInfo to full parity with the EXECUTING / getHitlAgentArtifact paths for multi-repo beam. It already preferred the loaded repo's in-scope LBV and forwarded its stepId, but it did not suppress out-of-scope sibling LBVs: when scope was set with no in-scope LBV it could still surface a sibling's LBV HITL to the IDE. Mirror the sibling branches: - when scope is set and every pending HITL is a sibling's LBV, return plan-only (surface nothing) - otherwise drop out-of-scope LBVs from the fallback pool so a sibling's LBV can't be picked in a mixed pending set Not a live false-green (the IDE scope guard already rejects a HITL whose stepId is out of the loaded subtree) — this restores the LSP-side layer so all three branches behave identically. Non-beam is byte-identical: the new logic is gated on a non-empty beam scope. * fix: harden beam LSP stepId coalescing and tidy beam docs - getStepId uses || so an empty-string id falls through to the next spelling (was ?? which let an empty id defeat coalescing and scope matching) - move the normalizeBeamRepo JSDoc onto normalizeBeamRepo (was stranded above getStepId) * test: cover beam LBV planning-scope and getStepId coalescing - PLANNING branch: a sibling repo's out-of-scope LBV is not surfaced - getStepId: empty stepId falls through to planStepId/parentStepId (|| not ??)
…es in telemetry (#2847) * fix(amazonq): only retry tool-use streams that were genuinely truncated Treating every response stream that ends without a terminating tool-use `stop` event as a truncated tool input is too broad. A stream also ends without `stop` when the request is aborted (response-processing timeout or cancellation), and when the model announced a tool use but streamed no input at all. Reporting those as failures and re-prompting the model produces failed intermediate stream events for turns that were not broken, and can re-run the agent loop without making progress. - finalize() now only reports an incomplete tool input when partial input was actually received and the request was not aborted; other unterminated tool uses are left unstopped and filtered out downstream, as before. - The abort state is passed into finalize() from the response processor. - Consecutive incomplete tool-use retries are now bounded (MAX_INCOMPLETE_TOOL_USE_RETRIES). On exceeding the limit the agent loop stops and surfaces an actionable error instead of retrying indefinitely. Genuine truncation (partial input present, request not aborted) still routes into the existing recovery path and is retried. * fix(amazonq): allow 3 incomplete tool-use retries before giving up * feat(amazonq): classify incomplete tool-use retries in invokeLLM telemetry A response stream whose tool-use input is cut off is retried inside the agent loop and usually recovers within the same user turn. Every one of those iterations emits amazonq_invokeLLM with result='Failed', so a per-call success rate built on that metric drops even though the user was unaffected. Report a `reason` alongside the existing result so the two cases can be told apart downstream: INCOMPLETE_TOOL_USE_RETRYING retry budget remains; transient, recovers INCOMPLETE_TOOL_USE_EXHAUSTED retries used up; the user sees an error The classification is computed before the emit. Because the retry budget is bounded, whether this iteration will be retried is already known at that point, so no post-hoc correlation is needed. result stays 'Failed' in both cases, so raw failure counts are unchanged and remain available for diagnostics. Consumers can now exclude the transient class from success-rate calculations while still counting the terminal give-up. The reason values are consumed by ToolkitTelemetryLambda to emit a separate EMF counter; renaming them requires updating that transform first. Retry behaviour is unchanged: incrementing the counter before the emit and testing `count <= MAX_INCOMPLETE_TOOL_USE_RETRIES` preserves the existing off-by-one, so 3 retries still follow the initial failure. * chore(amazonq): describe the telemetry reason consumer generically The do-not-rename note on the reason constants pointed at a specific internal consumer by name. Describe it as a downstream metrics pipeline instead: the warning is what matters to anyone editing these values, and the constants are part of a contract rather than a link to one particular implementation. No functional change.
Co-authored-by: aws-toolkit-automation <>
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com> Co-authored-by: Laxman Reddy <141967714+laileni-aws@users.noreply.github.com>
Co-authored-by: aws-toolkit-automation <>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
5 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Automatic merge failed
Command line hint
To perform the merge from the command line, you could do something like the following (where "origin" is the name of the remote in your local git repo):