Skip to main content

@siglo/fastify Adapter Guide

@siglo/fastify provides an idiomatic Fastify route handler adapter for executing Siglo workflows. It is optimized for high-throughput, low-overhead microservices, taking advantage of Fastify’s asynchronous request lifecycle, schema validation, and raw Node.js HTTP stream signals for cooperative cancellation.

1. Overview & Architecture

Fastify is designed for minimal overhead. The @siglo/fastify handler adapter integrates as a standard Fastify route handler:

2. Installation & Requirements

Install @siglo/fastify alongside Fastify:
Peer dependency matrix:
  • Siglo: * (v1.0.0+)
  • fastify: ^4.0.0 || ^5.0.0

3. API Reference

sigloFastifyHandler(workflow, options)

[!NOTE] Backward Compatibility: rivuletFastifyHandler is exported as an identical alias for legacy workflows.
Creates a Fastify route handler (request, reply) => Promise<any>:

4. Configuration Options (SigloFastifyOptions)

Without a custom output callback, a workflow result with status: 'waiting' returns 202 Accepted with the suspension descriptor as JSON. Completed workflows use the normal 200 OK response. Suspension is a successful result and does not invoke onError. A custom output callback controls both the response body and status.

5. Status Code Resolution & Error Semantics

If a workflow throws an unhandled error and no onError hook is specified, the adapter automatically categorizes the error and formats the response: Default Error JSON Payload:

6. Native Request Abort & Cooperative Cancellation

Fastify exposes Node.js’s native request.raw.signal. When an HTTP client aborts (e.g. closes connection or timeout occurs on the client proxy), Fastify emits an abort event on request.raw.signal. The adapter extracts request.raw.signal and attaches it to the workflow’s ExecutionOptions. Any workflow step calling external APIs can link their child operations:

7. Complete Production Example


8. Durable Workflows and Automatic HTTP Responses

Enable durable: true so waitForEvent() or wait() can suspend execution. The adapter automatically returns 202 Accepted when the result has status: 'waiting', including the suspension descriptor and X-Workflow-Stack-Id header. A workflow that completes uses 200 OK by default.
The waiting JSON includes status, stackId, stepId, correlationKey, eventName, expiresAt (a Unix timestamp in milliseconds when a timeout is set), and continuationStepIndex. Suspension is a successful result, so it does not invoke onError. Calling the submission handler again starts a new execution; approval webhooks must call resumeWorkflow() to continue the suspended one. For request-specific control, replace durable: true with durable: (req) => req.headers['x-durable'] === 'true'. Headers, query parameters, and JSON fields do not automatically enable durable mode in this adapter. Explicit durable: false disables suspension; wait nodes then use their non-durable behavior. A custom output callback takes full control of the response body and status, including for waiting results. If you supply one, handle result.status === 'waiting' explicitly when you want to preserve the 202 response. The HTTP adapter does not supply persistence. Configure a shared storage adapter that supports checkpoints and wait records to survive process restarts and resume across replicas. Timer waits also need a scheduler to resume them when due. See Durable Workflows, Storage and Adapters, and the distributed checkout tutorial.