mirror of
https://github.com/QwenLM/qwen-code.git
synced 2026-08-05 14:52:00 +00:00
d1648b3af9
* feat(telemetry): track tool execution outcomes Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com> * fix(telemetry): address execution-status review feedback (#8180) - Update stale nonInteractiveToolExecutor expectations for executionStatus (red CI) - Scope the cancelled span-status short-circuit to tool_call events so other cancelled events carrying an error keep ERROR status - Record loop-detection skips as UNKNOWN, not EXECUTION_DENIED, keeping the denial metric accurate - Assert execution_status on the resolved-with-error PostToolBatch path - Raise tool-call observer-failure logging from warn to error - Clarify subagent-projection exclusion and JSONL compatibility in design doc * fix(core): address review findings 3-6 on tool execution status (#8180) - recordToolExecutionMetrics now merges common attributes (session.id opt-in) like every other counter in metrics.ts - Lift TOOL_FAILURE_KIND_ATTRIBUTE / TOOL_FAILURE_KIND_CANCELLED into telemetry/constants.ts so coreToolScheduler and session-tracing share one definition - Add debugLogger to runToolTelemetrySink catch (was silent) - Replace delete-based absence in withPostToolBatchStop with conditional spread * fix(core): address remaining review findings on tool execution status (#8180) - Pass the frozen executionStatus variable instead of the literal 'success' in the post-hook-stop error response, keeping the frozen value the single source of truth (finding 4) - Force-finalize the deferred PostToolBatch parent span in the abort drain, since that terminal path cancels the batch hook that otherwise owns the span; documents the invariant at the call site (finding 6) - Comment the loop-detection guard so the permission-cancellation exclusion from invalid-param loop detection is explicit (finding 9) - Rename the design doc to the dated docs/design convention and note the schedule()/handleConfirmationResponse() resolution contract change for embedders (finding 2, doc convention) * docs(core): note schedule() resolution contract in tool execution status design (#8180) Record the embedder-facing behavior change that schedule() and handleConfirmationResponse() resolve with a terminal error call rather than rejecting, so a failing tool no longer aborts its siblings. * fix(telemetry): address review feedback for tool execution status (#8180) - Document the new tool_call attributes (call_id, execution_status), the qwen-code.tool.execution.count metric, the tool.execution span attributes, and the tool.failure_kind=cancelled span field in telemetry.md. - Pass ToolErrorType explicitly at loop-detection skip sites instead of inferring it from the skip message string, so copy edits cannot silently reclassify loop skips as approval denials. - Simplify withPostToolBatchStop response construction (drop the destructure-and-reattach used to preserve a missing execution status). - Add a debug breadcrumb when a PostToolBatch stop has no span to attach to, and a one-time warning when PostToolBatch hook detection fails open. - Drop the try/catch wrapping the pure isTelemetrySdkInitialized getter. - Clarify the design doc invalid-combination wording and note that the execution-failure SLI cannot be attributed to a specific tool. - Add a regression test pinning that schedule() resolves (not rejects) when a tool execution throws. * fix(telemetry): address round-7 review feedback for tool execution status (#8180) * fix(telemetry): restore type-safety fallback for executionErrorType (#8180) * fix(telemetry): align tool execution failure outcomes Keep Core and ACP cancellation arbitration consistent, preserve structured post-processing errors, and restore QwenLogger MCP metadata privacy. Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com> * fix(core): address review suggestions for tool execution status (#8180) * test(core,cli): strengthen test-efficacy for tool execution status (#8180) * fix(core): address review suggestions for tool execution status (#8180) - Improve post-processing cancellation message to indicate the tool had already completed, preventing silent model redo of completed work - Remove dead !isExecutionTimeout conjunct in Session.ts PostToolUse cancellation check (unreachable: timeout always sets toolResult.error) - Replace construct-then-delete with destructuring in withPostToolBatchStop - Move all failure-kind constants to telemetry/constants.ts so the full documented vocabulary lives in one place - Re-export StructuredToolError from tool-error.ts instead of importing from the unrelated priorReadEnforcement module - Add JSDoc to normalizeToolCallEvent documenting key-absent semantics - Add ordering-safety comment to createParentAbortRace microtask guarantee - Document endToolExecutionSpan not_started guard as defence-in-depth - Document PostToolBatch span leak window in finalizeToolSpan - Add design doc note about hand-placed cancellation check invariant - Add test for unknown execution_status normalization path - Revert unrelated generate-notices.js formatting change * fix(core): address review feedback for tool execution status (#8180) - Gate cancel message on executionThrew so the model sees 'User cancelled tool execution.' when execute() rejected under abort, reserving 'already completed' wording for post-processing cancels - Move StructuredToolError into tool-error.ts to break the tool-error ↔ priorReadEnforcement module cycle - Revert unrelated Prettier reformat in generate-notices.js * test(core): pin both tool cancellation notices; extract them as constants afd349ca gated the cancel message on executionThrew but left the two wordings as bare literals at four sites and added no test. That is the exact shape the bug had: it was introduced by editing one literal and missing the others. Extract TOOL_CANCELLED_{BEFORE,AFTER}_COMPLETION_MESSAGE so the four sites cannot drift, and add regression tests for both paths — a tool interrupted mid-flight (execute() rejected under abort) must report "User cancelled tool execution.", while a cancel after execute() returned must report that the output was discarded. The mid-flight test fails against the pre-afd349ca behaviour. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * fix(core): keep MCP reconnect for a timeout on a dead transport Classifying every `-32001` as EXECUTION_TIMEOUT skips handleReconnectOnError, which previously recovered one real case: the transport dies mid-request, the SDK request times out because no response will ever arrive, and the server is already recorded DISCONNECTED. That reconnected and retried; now it hard-fails and the user has to retry by hand. Divert back to the reconnect path only on positive evidence the transport is dead. Note that getMCPServerStatus() reports DISCONNECTED for servers it has never seen, so the guard checks for a *recorded* DISCONNECTED — the naive comparison misroutes every timeout from a server whose status was never registered, which broke four existing timeout tests when tried. A timeout on a healthy server is still EXECUTION_TIMEOUT: retrying it after a reconnect would just double the wait. The client-side idle timeout keeps classifying unconditionally; it is our own timer, not a transport signal. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * fix(core): address blocking review feedback for tool execution status (#8180) Two blocking items from the maintainer review: 1. Post-processing cancellations dropped persistedOutputFiles (and visionBridgeNotice) along with the model-visible output, orphaning files the tool had already spilled to disk. createCancelledResponse now carries both, and every cancelAfterPostProcessing site passes what it has; the settle-then-abort and hook-stop paths do the same. 2. A -32001 that lands while the parent signal is aborted is the SDK's abort rejection or a timeout that raced with a cancel; classifying it EXECUTION_TIMEOUT would count user cancels against the timeout SLI. isExecutionTimeoutFailure now defers to the abort in both catch blocks, regardless of which side settled the race first. The two tests that pinned the opposite timeout-wins ordering are updated to the abort-wins semantics the review asked for. Co-Authored-By: Qwen Code <noreply@alibaba-inc.com> --------- Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com> Co-authored-by: Shaojin Wen <shaojin.wensj@alibaba-inc.com> Co-authored-by: qwen-code-dev-bot <qwen-code-dev@service.alibaba.com> Co-authored-by: qwen-code-dev-bot <qwen-code-dev-bot@users.noreply.github.com> Co-authored-by: qwen-code-bot <qwen-code-bot@users.noreply.github.com> Co-authored-by: qwen-code-ci-bot <253268222+qwen-code-ci-bot@users.noreply.github.com> Co-authored-by: Qwen Code Autofix <qwen-code-autofix@users.noreply.github.com> Co-authored-by: qwen-code-ci-bot <qwen-code-ci-bot@users.noreply.github.com> Co-authored-by: Claude Opus 5 <noreply@anthropic.com> Co-authored-by: Qwen Code <noreply@alibaba-inc.com> |
||
|---|---|---|
| .. | ||
| _meta.ts | ||
| deployment.md | ||
| integration-tests.md | ||
| issue-and-pr-automation.md | ||
| npm.md | ||
| telemetry.md | ||