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

  1. Send a new message in the same thread to resume the conversation; the suspension state is recoverable.
  2. If aborts are unexpected, check the abort source (client timeout, proxy, or a correction flow that aborts the parent).
  3. Increase the client/proxy timeout if the abort is purely a timeout during long user deliberation.
  4. 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

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


AI-assisted analysis of n8n-io/n8n@5ac6606e81 (2026-08-12). Data as JSON: /api/errors/14bd73ada086afb5. Report an issue: GitHub.