n8n-io/n8n · error
The assistant was interrupted while waiting for your respons
Error message
The assistant was interrupted while waiting for your response. Send a new message to continue.
What it means
Thrown by waitForConfirmation in resumable-stream-executor.ts when the AbortSignal fires (or is already aborted) while the assistant is suspended waiting for a HITL confirmation. The message is user-facing and instructs them to send a new message to resume. It fires both for a pre-aborted signal (line 636) and for an abort that arrives during the Promise.race (line 648-653).
Source
Thrown at packages/@n8n/instance-ai/src/runtime/resumable-stream-executor.ts:637
return {
__correctionOverride: true,
message:
'The user sent a correction while this run was active. ' +
'The confirmation has been skipped. Apply the correction and continue.',
corrections,
};
}
function isErrorChunk(chunk: unknown): chunk is { type: 'error'; error?: unknown } {
return isRecord(chunk) && chunk.type === 'error';
}
async function waitForConfirmation(
signal: AbortSignal,
confirmationPromise: Promise<Record<string, unknown>>,
): Promise<Record<string, unknown>> {
if (signal.aborted) {
throw new Error(
'The assistant was interrupted while waiting for your response. Send a new message to continue.',
);
}
let abortHandler: (() => void) | undefined;
try {
return await Promise.race([
confirmationPromise,
new Promise<never>((_, reject) => {
abortHandler = () =>
reject(
new Error(
'The assistant was interrupted while waiting for your response. Send a new message to continue.',
),
);
signal.addEventListener('abort', abortHandler, { once: true });
}),View on GitHub (pinned to 5ac6606e81)
Solutions
- Send a new message in the same thread to resume the conversation; the suspension state is recoverable.
- If aborts are unexpected, check the abort source (client timeout, proxy, or a correction flow that aborts the parent).
- Increase the client/proxy timeout if the abort is purely a timeout during long user deliberation.
- Verify no other code path is signaling the AbortController prematurely.
Defensive patterns
Strategy: try-catch
Validate before calling
// No pre-call validation; the abort can arrive at any time. // Instead, ensure the AbortController is only aborted for genuine stop requests.
Try / catch
try { await waitForConfirmation(signal, confirmationPromise); }
catch (e) {
if (e instanceof Error && e.message.includes('interrupted while waiting')) {
// keep the thread alive; user can send a new message to resume
return { status: 'interrupted' };
}
throw e;
} Prevention
- Only abort for genuine stop requests; do not abort on transient timeouts if HITL is expected.
- Lengthen client/proxy timeouts for runs that may pause for user confirmation.
- Preserve suspended-run state so a new message can resume it.
- Audit other code paths (correction handlers) that may abort the parent run prematurely.
When it happens
Trigger: A user clicks stop/cancel (or the request is aborted by timeout/client disconnect) while a tool-call-suspended chunk is awaiting confirmation data. The AbortSignal trips and waitForConfirmation rejects before the confirmation promise resolves.
Common situations: User cancels a run mid-confirmation; client disconnects during a long HITL pause; a timeout aborts the request; a correction handler aborts the original run to start a new one.
Related errors
- ${agentLabel} ${reason}
- Run ${runId} is not suspended. Cannot resume.
- Sub-agent tool requires confirmation but no HITL handler is
- Invalid hitl input for tool ${toolkitTool.name}
- Human-in-the-Loop nodes cannot be used inside a sub-agent. M
AI-assisted analysis of n8n-io/n8n@5ac6606e81 (2026-08-12).
Data as JSON: /api/errors/14bd73ada086afb5.
Report an issue: GitHub.