FlowiseAI/Flowise · info · Error
Aborted!
Error message
Aborted!
What it means
Thrown at the top of the `agentNode` runnable when `abortControllerSignal.signal.aborted` is already true. This is the cooperative cancellation contract: before each agent invoke the node checks the shared AbortController and bails out fast rather than burning LLM tokens on a run the user has stopped.
Source
Thrown at packages/components/nodes/sequentialagents/Agent/Agent.ts:789
nodeData,
input,
options
}: {
state: ISeqAgentsState
llm: BaseChatModel
interrupt: boolean
agent: AgentExecutor | RunnableSequence
name: string
abortControllerSignal: AbortController
nodeData: INodeData
input: string
options: ICommonObject
},
config: RunnableConfig
) {
try {
if (abortControllerSignal.signal.aborted) {
throw new Error('Aborted!')
}
const historySelection = (nodeData.inputs?.conversationHistorySelection || 'all_messages') as ConversationHistorySelection
// @ts-ignore
state.messages = filterConversationHistory(historySelection, input, state)
// @ts-ignore
state.messages = restructureMessages(llm, state)
let result = await agent.invoke({ ...state, signal: abortControllerSignal.signal }, config)
if (interrupt) {
const messages = state.messages as unknown as BaseMessage[]
const lastMessage = messages.length ? messages[messages.length - 1] : null
// If the last message is a tool message and is an interrupted message, format output into standard agent output
if (lastMessage && lastMessage._getType() === 'tool' && lastMessage.additional_kwargs?.nodeId === nodeData.id) {
let formattedAgentResult: {
output?: stringView on GitHub (pinned to abe4a8601a)
Solutions
- Treat this as expected behaviour when the user intentionally cancelled — surface a 'stopped' message in the UI rather than an error.
- If you are calling programmatically, create a fresh `AbortController` for each run instead of reusing one.
- Do not call `abort()` unless you intend to cancel; check for accidental timeout/abort wiring.
- If abort fires from a timeout, raise the timeout or remove the abort side-effect.
Defensive patterns
Strategy: try-catch
Validate before calling
function isAborted(signal) {
return !!signal?.aborted
}
// before invoking the agent node
if (isAborted(abortControllerSignal.signal)) {
return { status: 'cancelled', output: 'Run cancelled before start.' }
} Type guard
function isAbortSignal(v): v is AbortSignal {
return v != null && typeof v.aborted === 'boolean'
} Try / catch
try {
await agentNode({ ...state, abortControllerSignal, ... }, config)
} catch (e) {
if (e?.message === 'Aborted!') {
// expected on user cancel — surface a friendly message, do not log as error
return { status: 'cancelled' }
}
throw e // real error — rethrow
} Prevention
- Create a fresh AbortController per run; do not reuse aborted ones.
- Treat 'Aborted!' as a cancellation signal in UI code, not an error.
- Make sure timeouts do not call abort unintentionally.
When it happens
Trigger: The user clicks Stop in the Flowise UI; the client disconnects; an upstream timeout calls `abortController.abort()`; or `agentNode` is invoked with an AbortController whose signal was already aborted before the call.
Common situations: User clicked Stop mid-run; the front-end cancelled the fetch; a tool triggered abort on a custom condition; an AbortController was reused across runs and was aborted by a previous request.
Related errors
- Aborted!
- Failed to load fs/promises. Make sure you are running in Nod
- Failed to load fs/promises. Make sure you are running in Nod
- Please install huggingface as a dependency with, e.g. `pnpm
- Please install replicate as a dependency with, e.g. `yarn ad
AI-assisted analysis of FlowiseAI/Flowise@abe4a8601a (2026-08-12).
Data as JSON: /api/errors/fa950745528bbcb7.
Report an issue: GitHub.