> ## Documentation Index
> Fetch the complete documentation index at: https://filla.io/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Error handling

> Configure how a processor tool handles records that fail to process.

## The three error modes

Every processor tool has an **On error** setting that controls what happens when a record fails to process.

| Mode            | Behavior                                                                                   |
| --------------- | ------------------------------------------------------------------------------------------ |
| **Stop**        | The run halts immediately when any record fails. No further records are processed.         |
| **Continue**    | Failed records are logged and skipped, but the run continues with the rest of the records. |
| **Skip record** | Similar to Continue. The failed record is skipped and processing moves to the next one.    |

## Choosing the right mode

**Use Stop when:**

* A failure means something is fundamentally wrong with the tool configuration
* You want to catch issues early before they affect many records
* The tool is making irreversible changes (like deleting records) and you want to be cautious

**Use Continue or Skip when:**

* Some records are expected to fail (missing values, unusual formats)
* You want to process as many records as possible and review failures separately
* The failures are isolated and don't indicate a systemic problem

## Viewing errors

Failed records are logged in the execution log with a timestamp, the record ID, and the error message. Review the log after a run to understand what went wrong.

The run metrics show the split between succeeded and failed records at a glance.

## Common error causes

| Situation             | Typical cause                                                                                        |
| --------------------- | ---------------------------------------------------------------------------------------------------- |
| Record skipped        | The record's source field is empty and "Skip empty fields" is on                                     |
| Network error         | The tool made an external API call (geocoding, email validation) that failed                         |
| File processing error | An attachment was corrupted, too large, or in an unsupported format                                  |
| Airtable write error  | Rate limiting, permission issue, or field type mismatch                                              |
| Invalid value         | The source field contains a value the tool cannot process (e.g., non-numeric data in a number field) |

## Re-running after errors

After fixing the underlying issue, you can re-run the tool. If you have a "Skip already processed" or "Skip non-empty output" option, enable it to skip records that succeeded on the first run and only reprocess the ones that failed.

Alternatively, filter the tool to run only on the specific records that failed by adding a filter condition on the record IDs or a status field you set during the failed run.

## Common questions

<AccordionGroup>
  <Accordion title="Is there a way to automatically retry failed records?">
    Not automatically. After a run, identify the failed records from the execution log and re-run the tool with a filter targeting only those records.
  </Accordion>

  <Accordion title="Does a failed record still get written to Airtable?">
    No. If a record fails processing, Filla does not write any output for that record. The original Airtable data is unchanged.
  </Accordion>

  <Accordion title="Can I get a list of all failed record IDs?">
    Check the execution log for the run. Each failure entry includes the record ID and the error message. The log is available in the run history panel.
  </Accordion>
</AccordionGroup>
