Docs / Strand / advanced/error-handling

Error Handling

Learn how to handle errors in Strand workflows.

Overview#

Errors can occur at various points in workflow execution. Strand provides several mechanisms for handling them gracefully.

Error Types#

Node Execution Errors#

When a node fails to execute:

Workflow Errors#

Error Handling Strategies#

Default Values#

Use the default filter to handle missing data:

jinja

{{ payload.email | default('unknown@example.com') }}

Conditional Checks#

Check for data existence before using:

jinja

{% if steps.user_lookup.output_payload %}
  {{ steps.user_lookup.output_payload.email }}
{% else %}
  {{ 'No user found' }}
{% endif %}

Error Information#

When a node fails, error information is available:

Best Practices#

Error Handling Tips
  1. ✅ Always handle HTTP request errors
  2. ✅ Use if/else branching to check for error conditions
  3. ✅ Log errors with print nodes for debugging
  4. ✅ Provide fallback values with default
  5. ✅ Test error scenarios
  6. ✅ Monitor error rates in production

Common Error Scenarios#

Missing Data#

Problem: Referencing data that doesn't exist

Templates render in strict mode: referencing a missing variable or key raises an error rather than producing an empty string. Depending on where the template runs, this can fail the step (If/Else conditions and sub-workflow inputs), set a field to null (Transform mappings), or pass the raw template text through (other node configs). Always guard optional fields.

Solution:

jinja

{{ payload.user.email | default('no-email@example.com') }}

See Jinja2 Error Handling for the full per-context behavior table.

Template Errors#

Problem: Invalid Jinja2 syntax

Solution:

Network Errors#

Problem: External API unavailable

Solution: