Skip to main content

Return

Control Flow Pipeline

Synopsis​

Exits early from the current processor block (group, pipeline, or foreach), similar to a return statement in programming languages.

Schema​

- return:
    description: <text>
    if: <script>
    tag: <string>

Configuration​

The following fields are used to define the processor:

FieldRequiredDefaultDescription
descriptionN-Explanatory note
ifN-Condition to run
tagN-Identifier
disabledNfalseWhen true, the processor is skipped and the event continues to the next one. Lets you take a processor out of the path without removing its configuration
note

This processor does not accept on_success, on_failure or ignore_failure. Its whole job is to signal a control-flow decision to the pipeline runner, and it returns that signal directly — there is no success or failure outcome for a handler to run against. if, tag and disabled work normally.

Details​

The return processor exits early from the current execution block, halting any remaining processors within that scope. It behaves like a return statement in typical programming languages, allowing you to exit a function or block early based on conditions.

Scope Behavior:

  • Inside a foreach processor: Exits the current item's processing and moves to the next item
  • Inside a group processor: Exits the group and continues with the next processor after the group
  • Inside a pipeline processor: Exits the nested pipeline and returns to the parent pipeline
  • At the top level: Completes processing of the current event and continues to the next event

The processor returns immediately once its condition passes. It runs no handlers of its own, so any marking, logging or metrics step has to be placed ahead of it in the pipeline.

Return vs Continue

return exits the current block entirely, while continue (in foreach contexts) skips to the next iteration. Use return for early exit logic and continue for iteration control.

Use Cases
  • Skip expensive processing for events that don't need it
  • Exit early after successful completion of a task
  • Implement conditional processing paths
  • Optimize performance by avoiding unnecessary operations

Examples​

Early Exit from Group​

Exiting a processing group early...

- group:
    processors:
      - set:
          field: processed
          value: true
      - return:
          if: "skip_advanced == true"
          description: "Exit group if advanced processing not needed"
      - expensive_operation:
          field: data
      - complex_transform:
          field: result
- set:
    field: final_step
    value: true

exits the group early, skips expensive operations:

{
  "processed": true,
  "skip_advanced": true,
  "final_step": true
}

Conditional Processing Path​

Implementing conditional logic with return...

- set:
    field: validation_started
    value: true
- return:
    if: "already_validated == true"
    description: "Skip validation if already done"
- validate:
    field: required_field
    exists: true
- enrich:
    field: user_id
    target: user_details

skips validation steps when not needed:

{
  "validation_started": true,
  "already_validated": true
}

Exit from Nested Pipeline​

A nested pipeline called via the pipeline processor...

pipelines:
  - name: enrichment-pipeline
    processors:
      - enrich:
          field: ip_address
          target: geo_data
      - return:
          if: "geo_data.country == 'US'"
          description: "Skip international enrichment for US"
      - international_enrichment:
          field: geo_data

is invoked from the parent pipeline:

- pipeline:
    name: '{{ IngestPipeline "enrichment-pipeline" }}'
- set:
    field: enrichment_complete
    value: true

Return exits the nested pipeline for US events, continuing in the parent:

{
  "ip_address": "192.0.2.1",
  "geo_data": {"country": "US"},
  "enrichment_complete": true
}

Performance Optimization​

Skipping expensive processing for filtered events...

- set:
    if: "log_level == 'DEBUG'"
    field: processing_tier
    value: "minimal"
- return:
    if: "log_level == 'DEBUG'"
    description: "Skip expensive processing for debug logs"
- complex_analysis:
    field: message
- ml_enrichment:
    field: data
- threat_detection:
    field: indicators

bypasses expensive operations for debug logs:

{
  "log_level": "DEBUG",
  "processing_tier": "minimal"
}