Skip to content
VB-OSVB-OSVB-OS Docs

VB-OS Flow Failure Behavior

Webhook Retries

Section titled “Webhook Retries”

Webhook action dispatches support configurable retry behavior:

  • max_attempts: number of delivery attempts (1–5)
  • backoff_seconds: delay between retries (1–60 seconds)

If all attempts fail, the dispatch is marked FAILED and the execution status reflects the failure.

Categorical Map Fail-Closed

Section titled “Categorical Map Fail-Closed”

When a connector evidence mapping uses categorical_map and the source value does not match any key in the mapping, the gather fails closed:

  • No evidence is produced for that field
  • If auto-evaluate is enabled, the evaluation receives incomplete evidence
  • Missing required evidence produces DEFER at Stage 1 (admissibility)

This prevents unmapped values from silently passing through the evaluation pipeline.

Acquisition Rejections

Section titled “Acquisition Rejections”

Evidence acquisition can be rejected before evaluation:

  • Scope resolution failure: a scoped connector cannot resolve its subject, producing zero evidence
  • Acquisition class policy: if the effective acquisition class is not in the connector’s allowed_acquisition_classes, the gather is rejected

Orphaned Dispatch Recovery

Section titled “Orphaned Dispatch Recovery”

If the platform restarts while dispatches are in progress, orphaned dispatches (in PENDING state) are reconciled on startup. The reconciliation process checks each orphaned dispatch against its max_attempts limit: if the dispatch has exhausted all attempts, it is marked FAILED; otherwise it remains eligible for retry. When all dispatches for an execution reach a terminal state (SUCCEEDED or FAILED), the execution status is updated accordingly. Retry with backoff is primarily applied during this orphaned dispatch reconciliation.

Duplicate Prevention

Section titled “Duplicate Prevention”

Multiple safeguards prevent duplicate processing:

Level Mechanism
Execution Unique constraint on (deployment_id, evaluation_id)
Dispatch Idempotency key {execution_id}:{node_id}
Webhook Delivery includes idempotency metadata for receiver-side dedup

Every Flow Must Have a Defer Action

Section titled “Every Flow Must Have a Defer Action”

Flow validation requires at least one defer_action node. This enforces fail-closed design: every evaluation that produces DEFER is handled explicitly, never silently dropped.

Next Steps

Section titled “Next Steps”