@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:
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 noonError 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 nativerequest.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
Enabledurable: 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.
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.