Skip to main content
Feature ID: FW-46
Status: ✅ Complete
Spec Reference: FW-46-durable-execution-worker.md
Last Updated: 2026-03-16

​
Overview

FW-46 introduces a durable, queue-backed workflow execution worker that processes fw_workflow_executions records from queued/retry_pending states using pgmq plus scheduled worker invocation. The integration reuses existing FW execution logic (automation-executor) and platform primitives (PF-01 tenant model, PF-10 notification delivery), while adding dead-letter routing and retry-safe checkpointing.

​
Integration Points (from Spec)

​
API / Platform Contracts

  • Worker edge function (planned): workflow-executor-worker
    • Triggered on schedule and processes batched queue messages.
  • Database function (planned): fw_claim_queued_executions()
    • FOR UPDATE SKIP LOCKED fallback claim path when queue read path is unavailable.
  • RPC function (planned): fw_enqueue_form_submission_automation()
    • User-callable enqueue path for form-submission automation bridge with org access validation.
  • Shared execution contract: worker delegates to existing FW-03 automation execution logic (single source of execution semantics).

​
Scheduled Processing Contract

  • Job Name: process-workflow-queue
  • Schedule: * * * * * (or */10 * * * * * when second-level pg_cron is available)
  • Invocation Target: workflow-executor-worker edge function
  • Batch Behavior: process queue in batches, acknowledge success, retry on transient failure, route permanent failures to workflow_dlq
  • Concurrency Safety: semaphore/state guard prevents overlapping worker runs

​
Event Contracts

FW-46 does not introduce a new external cross-core event contract in Phase 1. It extends FW internal event-processing flow by connecting FW-16 queued execution production to worker consumption and execution orchestration.

​
Security and Tenant Isolation

  • Queue payloads contain only operational identifiers (execution_id, rule_id, organization_id), not PHI/PII.
  • Worker runtime uses service-role credentials via Vault; no end-user token storage in queue messages.
  • Organization scoping is verified at message processing time against execution records.
  • User-callable enqueue RPC validates org access (fw_has_org_access()) before accepting requests.
  • Error persistence uses sanitized messages; internal stack traces are not exposed.