Skip to main content

Execution Model

Zerq executes a workflow as a directed graph bound to a published proxy revision. Each run carries a context object, profile metadata, and request headers so downstream nodes can make deterministic decisions.

Runtime model​

  • Entry trigger: http_trigger supplies gateway request fields to the graph. manual_trigger is for builder/test runs and outputs triggered_at and trigger (manual) only.
  • Single run context: every node reads from and writes to the same run context.
  • Deterministic order: edges define the next node; parallel branches merge only through explicit join logic.
  • Branch contracts: success/error/valid/invalid branches are explicit outputs, not implied behavior.
  • Policy awareness: client, profile, and policy decisions happen before protected nodes execute.

Inputs that change behavior​

  • Selected collection and published proxy revision.
  • X-Client-ID and X-Profile-ID headers used for policy/profile resolution.
  • Authorization credential (JWT, token, OIDC token, or mTLS identity mapping).
  • Node-level timeout/retry settings and fallback outputs.

Branching and error semantics​

  • Validation nodes route to valid or invalid outputs.
  • Processing nodes route to success or error outputs.
  • Method restrictions should reject unsupported verbs with 405 before heavy processing.
  • Auth failures should return 401; policy denies should return 403; rate controls should return 429.

Validation steps​

  1. Send a baseline request that should succeed for the expected collection and proxy.
  2. Repeat the same request with a different X-Profile-ID to confirm profile isolation.
  3. Remove or alter Authorization and confirm the deny path returns 401 or 403.
  4. Burst requests to confirm throttling behavior and watch for 429 when limits are exceeded.
  5. Review request logs and audit logs to confirm actor, client, profile, and policy decision.

Example: order lookup workflow​

Scenario: proxy orders-v2 receives GET /orders/123 for partner client acme-mobile.

curl -i https://gateway.example.com/orders/123 \
  -H "Authorization: Bearer $TOKEN" \
  -H "X-Client-ID: acme-mobile" \
  -H "X-Profile-ID: partner-prod" \
  -H "Accept: application/json"

Expected behavior:

  1. http_trigger captures headers, path, query, and body.
  2. validate_node routes valid if orderId matches schema.
  3. Gateway auth/policy checks enforce X-Client-ID and X-Profile-ID before proxy execution.
  4. http_request_node or proxy_node runs on success; failures route error.
  5. response_node returns 200 on success and mapped 4xx/5xx on failures.

What to inspect when behavior drifts​

  • Wrong branch wiring (for example, invalid connected to success response).
  • Retry enabled for non-idempotent nodes, causing duplicate side effects.
  • Draft workflow tested without publishing the updated proxy revision.
  • Header mismatch (X-Profile-ID not bound to the active collection).