Reference
Masking, loops, and error handling
Reference for deterministic test-data masking, repeated task pipelines, continuation checks, safety caps, and per-item failure behavior.
These features affect data safety and execution lifetime. Configure explicit bounds and test failure behavior before using them on production-scale data.
PII masking
Task-level masking controls Envoy's JSONata masking functions:
masking:
enabled: ${MASK_PII}
seed: ${MASK_SEED}Functions include:
$mask(value, type?, options?);$maskEmail(value, options?);$maskPhone(value);$maskName(value);$maskText(value);$maskingEnabled().
When masking is disabled, these functions return the original value. When enabled, masking is deterministic for the same value and seed so test relationships can remain joinable.
Keep the seed in deployment secret management. Changing it changes generated tokens.
Deterministic masking is not cryptographic anonymization. Low-entropy values can still be guessed, and masked data remains subject to the organization's test-data policy.
Task loops
A top-level loop repeats the complete main pipeline within one task run:
loop:
sleep_ms: 30000
max_iterations: 100
max_duration_ms: 3600000sleep_ms is required and must be at least 10,000 milliseconds.
Continuation steps
loop:
sleep_ms: 15000
check_num_times: 3
steps:
- name: remaining
type: call_method
config:
connector: staging
method: count
args:
table: tickets
where:
status: pending
- name: continue
type: transform
config: "steps.remaining.output > 0"The final loop-step output is coerced to boolean. check_num_times requires consecutive false checks before exit.
Loop-step JSONata can read:
variables.envoy_iteration;variables.envoy_last_iteration_at;variables.envoy_false_count.
until_empty
loop:
sleep_ms: 15000
until_empty:
from_step: fetch_one_pendingEnvoy re-executes the named main step in isolation as a continuation check. Make it a lightweight existence query such as a count or limit: 1, not the full extraction.
Use output: none or ndjson. A looping task with output: json accumulates results.
Step error handling
error_handling: failfailstops the task and is the default.ignorelogs the error and lets other items continue.ignore_restskips the remaining pipeline for the affected item.
Use ignore only with an explicit reconciliation path. A failed step does not produce a valid success response.
Guarded continuation
After an ignored write:
- name: mark_complete
type: call_method
skip_if: "$not(steps.create.output.id)"
config: |
{ ... }Record a separate error state when the create output is absent. Do not write a destination mapping or success marker from an empty result.
Cancellation and limits
A loop exits on its configured cap, a false continuation condition, or task cancellation. Stopping it does not reverse completed connector calls.
Always set max_iterations or max_duration_ms for a bounded operational workflow. Use a schedule for discrete auditable runs when one long-lived run is unnecessary.
See Task structure and Debugging.