<!-- BusyBot node reference — https://busybot.net/tools/stop-and-error/ -->

> Node: Stop and Error (`stop_and_error`) · Action · v1
> Category: Core Nodes · Credentials: none
> Updated: 2026-08-16

# Stop and Error

> Throw an error to stop workflow execution

## Overview

The Stop and Error tool intentionally throws an error to halt workflow execution. It supports two modes: a simple error message string, or a JSON error object with structured fields (message, description, code, type). Use this when a workflow should fail with a specific error under certain conditions.

**Category:** Core Nodes  
**Tool Name:** `stop_and_error`  
**Version:** 1

**Appearance:** Icon: `lucide-OctagonX` | Color: `#ff0000`

## Node Type

**Action** — processes input items and produces output

## Input / Output

| Direction | Port(s) |
|-----------|--------|
| Input | `Input` |
| Output | `Output`, `Error` |

## Credentials

This tool does not require any credentials.

### Parameters

| Parameter | Type | Required | Default | Description |
|-----------|------|----------|---------|-------------|
| Error Type | `options` | No | `errorMessage` | Type of error to throw. |
| | | | | Options: `errorMessage`, `errorObject` |
| Error Message | `string` | Yes | — | The error message to throw. _(shown when Error Type is `errorMessage`)_ |
| Error Object | `json` | Yes | — | Object containing error properties. Supports fields: message, description, error, code, type. _(shown when Error Type is `errorObject`)_ |
| Max Concurrency | `number` | No | `10` | Maximum number of items to process concurrently. |

## Output Data

This node always fails the items it receives — that is its whole purpose. What reaches the rest of the workflow depends on the node's error-handling mode:

- **stop** — the first item throws and the workflow run halts. Nothing is emitted.
- **continue** (the default) — each input item is turned into an error item and leaves on `Output`, carrying an `_error` object alongside the original item JSON. Downstream nodes will see them, so check for `_error` before treating that branch as normal traffic.
- **errorPort** — the same error items are routed to the `Error` output instead, leaving `Output` empty.

The message on the error is resolved once for the whole node run:

- With **Error Type** `errorMessage`, the message is the Error Message text, or `Workflow stopped with error` when it is empty.
- With **Error Type** `errorObject`, the message is the object's `message`, falling back to `description`, then `error`, and finally to the whole object rendered as JSON. `description` is carried through when present, and the full object you supplied is attached to the error as its metadata. Text that is not valid JSON produces the message `Invalid error JSON: …` rather than silently succeeding.

## Usage Examples

- Stop workflow when invalid data is detected
- Throw custom error with structured JSON error object
- Halt execution with descriptive error message

## Example Configuration

Fail with a plain message:

```json
{
  "type": "stop_and_error",
  "parameters": {
    "errorType": "errorMessage",
    "errorMessage": "Validation failed: Required field is missing"
  }
}
```

Fail with a structured error object:

```json
{
  "type": "stop_and_error",
  "parameters": {
    "errorType": "errorObject",
    "errorObject": {
      "message": "Authentication failed",
      "description": "The provided API key is invalid or expired",
      "error": "INVALID_API_KEY",
      "code": 401,
      "type": "AuthenticationError"
    }
  }
}
```

Fail a validation branch, limiting how many items are processed at once:

```json
{
  "type": "stop_and_error",
  "parameters": {
    "errorType": "errorMessage",
    "errorMessage": "Invalid input: email address format is incorrect",
    "maxConcurrency": 5
  }
}
```

Return an API-style error:

```json
{
  "type": "stop_and_error",
  "parameters": {
    "errorType": "errorObject",
    "errorObject": {
      "message": "Resource not found",
      "description": "The requested user ID does not exist in the database",
      "error": "USER_NOT_FOUND",
      "code": 404,
      "type": "NotFoundError"
    }
  }
}
```

Raise a business-rule failure:

```json
{
  "type": "stop_and_error",
  "parameters": {
    "errorType": "errorObject",
    "errorObject": {
      "message": "Insufficient funds",
      "description": "Account balance is too low to complete this transaction",
      "error": "INSUFFICIENT_BALANCE",
      "code": 422,
      "type": "BusinessRuleError"
    },
    "maxConcurrency": 1
  }
}
```

### Error Handling

| Mode | Behavior |
|------|----------|
| **stop** | Halts workflow on first error |
| **continue** | Skips failed items, passes successful ones through |
| **errorPort** | Routes failed items to Error output port |

## Tips

Intentionally throws an error to stop workflow execution with a custom message or error object.

### Behavior notes

- **Put it behind a condition.** This node fails everything that reaches it, so gate it with an If or Switch node — wire only the branch that represents the failure case into it.
- **Set the node's error handling to `stop` if you want the run to actually halt.** On the default `continue` setting the error becomes an item and the workflow keeps going.
- **The error text is fixed, not per item.** Error Message and Error Object are read once for the node and used verbatim for every item, so write a message that makes sense on its own rather than one that depends on a particular record. To include values from the data, build the message in an upstream node and branch on it.