Node.js: external-tool result-delivery RPC failures are silently swallowed
Nadie ha tomado este issue todavía.
- #2909 de @FOWEPJF255 — cerrado sin fusionar
Evaluación
- Dificultad
- 4/5
- Tiempo estimado
- 3-5 días
- Aptitud para principiantes
- 42/100
- Tipo de issue
- Error
- Claridad
- Bien especificado
- Estado de actividad
- Activo
- Stack tecnológico
- javascript, node.js
Línea de trabajo
Start with nodejs/src/session.ts, especially _executeToolAndRespond and _claimExternalTool, then trace the result-submission RPC and its error handling. Add regression coverage for a handler that succeeds while delivery fails, alongside the existing success and handler-error cases. Done means unexpected delivery failures reach the host through a documented diagnostics or error path while cancellation, races, and teardown retain their intended behavior.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
Summary
The Node.js SDK silently swallows an unexpected failure while submitting a completed external-tool result through session.tools.handlePendingToolCall.
The tool handler succeeds, but result submission rejects. _executeToolAndRespond then resolves successfully without surfacing the delivery error. The request has already been removed from the SDK's pending invocation tracking.
If the runtime remains active and has not accepted the result, it can remain waiting for a response. This report does not establish that this code path caused any particular production timeout.
Environment and verification
- OS: Windows x64.
- Node.js: reproduced on both 24.16.0 and 27.0.0-alpha.0.0.0.
- Reproduced with the Node.js SDK bundled in platform package
@github/[email protected]. - The same control flow exists in public SDK main at commit
99d90edf504f824c77dcdf0faa978f4b35848a87. This source comparison is static; the reproduction below was executed against the installed bundle. - The reproduction uses internal SDK seams to isolate result delivery. It starts no runtime or model request and requires no credentials or network access.
Minimal reproduction
Save as repro.mjs in an environment with @github/copilot-sdk installed, then run node --test repro.mjs.
import assert from 'node:assert/strict';
import test from 'node:test';
import { CopilotSession } from '@github/copilot-sdk';
test('unexpected result-delivery errors are surfaced', async () => {
const session = new CopilotSession('repro-session', {});
let handlerCalls = 0;
let responseAttempts = 0;
session._rpc = {
tools: {
handlePendingToolCall: async () => {
responseAttempts++;
throw new Error('simulated result delivery failure');
},
},
};
await assert.rejects(
session._executeToolAndRespond(
'repro-request',
'repro-tool',
'repro-call',
{},
async () => {
handlerCalls++;
return 'done';
},
),
/simulated result delivery failure/,
);
assert.equal(handlerCalls, 1);
assert.equal(responseAttempts, 1);
});
Actual behavior
The test fails with Missing expected rejection.
A separate probe confirms that the handler ran once, result submission was attempted once, and the delivery error was not surfaced. The invocation was no longer present in pendingExternalTools.
On both tested Node.js versions, two positive controls pass and the result-delivery regression fails. The controls cover a successful result submission and a handler exception successfully submitted as an error response.
Expected behavior
An unexpected result-delivery failure should reach the host through an explicit, documented diagnostics or error path rather than silently resolving. Rejecting the internal method is one possible implementation; a structured host diagnostic would also address the observability problem.
Expected cancellation, stale-response rejection, duplicate-client races, and session teardown should retain their intended behavior.
Public source analysis
_executeToolAndRespondcalls_claimExternalToolbefore awaiting the result-submission RPC._claimExternalToolremoves the request frompendingExternalTools.- If result submission rejects, the enclosing catch calls
_claimExternalToolagain. - The second claim returns false because the first claim removed the entry.
- The catch returns without surfacing the delivery failure.
The ownership claim appears intentional for cancellation and race safety, so simply removing it or rerunning the handler would not be a safe fix.
Suggested fix direction
- Separate tool-handler failures from result-delivery failures.
- Keep the single-owner claim and cancellation guarantees.
- Surface unexpected result-delivery failures explicitly instead of routing them through a second ownership claim that suppresses them.
- If result retry is supported, retry only the completed result and document its idempotency guarantees. Do not rerun a tool that may already have produced side effects.
- Add regression coverage for successful delivery, handler failure, unexpected delivery failure, completion races, teardown, and late responses.
Related reports
- #2872 concerns the 1,800-second external-tool timeout and configuration documentation. It is closed, with no public comment or linked fix explaining a supported timeout override.
- #2368 concerns an event dropped before SDK handler entry and is closed as fixed. This report instead starts with a handler that already completed.
- #2509 introduced the request ownership and cancellation behavior and is merged.
- #2425 proposed handler-dispatch diagnostics but was closed without merging.
- Lenguaje dominante
- Java
- Estrellas
- 10.7k
- Forks
- 1.5k
- Métricas de merge de PR
- Sin PR fusionados en 30 d
Preparar el entorno
- Sin Dockerfile ni archivo de Docker Compose
- Sin plantilla de pull request
- Leer la guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de github/copilot-sdk
-
Rust: ElicitationRequest drops the tool call id from elicitation.requestedQuizá libre de nuevo Un pull request para esta issue se cerró sin fusionarse. Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
github/copilot-sdk#2900 ·
-
Bump zod version to 4.6.6.Abierto
Dificultad 1/5 Menos de una hora Aptitud para principiantes 84/100
github/copilot-sdk#2876 · 1 comentario · 1 reacción ·
-
Python ModelLimits drops max_output_tokens from model metadataQuizá libre de nuevo Un pull request para esta issue se cerró sin fusionarse. Abiertobug
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
github/copilot-sdk#2798 · 1 comentario ·
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 65/100
github/copilot-sdk#2759 ·
-
docs/AGENTS.md is repo authoring guidance, but everything in docs/ gets publishedQuizá libre de nuevo Un pull request para esta issue se cerró sin fusionarse. Abiertodocumentation
Dificultad 1/5 Menos de una hora Aptitud para principiantes 85/100
github/copilot-sdk#2758 ·
Todos los issues de github/copilot-sdk
Issues similares
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
ls1intum/thesis-management#1473 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 76/100
LunaDeerMC/Dominion#301 · 1 comentario ·
-
[FEATURE] Expose external refresh, node-level translog and warmer statsPosiblemente ocupada Un pull request vinculado a esta issue está abierto o ya se fusionó. Abiertountriaged
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
opensearch-project/opensearch-prometheus-exporter#680 ·
Los mantenedores suelen responder en 2 días
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 85/100
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 66/100
Los mantenedores suelen responder en 2 días