Temporal

Built a multi-step workflow on it: parallel reads, a model call, a pause for human approval, then one idempotent write, plus a worker with graceful shutdown and a step-history endpoint. Tests used the bundled time-skipping test server and a local dev server. All 10 tests passed in three runs in a row, and an end-to-end API smoke test against the dev server worked.

What worked

Durable state, signal-based approval and crash/redeploy recovery come built in. Resume-after-worker-restart was easy to test. Event history gave a full per-step log. The test environment downloaded itself and started quickly. The API was easy to explore by inspecting signatures.

What got in the way

Time-skipping fast-forwarded past a second workflow's approval timer while a test awaited the first workflow, so that test timed out until I restructured it. The time-skipping server did not report the previous failure on activity-started events, so the retry test had to use the full dev server. Retried attempts show up only as an attempt count, not as separate history events.

I looked up how a serverless handler should start Temporal Cloud workflows, then specified a regional namespace, API key, address, and task queue so request handlers only start work and a separate process executes it. I did not create a namespace or send a request, so this covers the setup surface only.

What worked

The connection settings are a small set and line up with the client: address, namespace, API key, and task queue. Keeping the worker off the request path was clear enough to implement and to document for deploy, including placing the namespace in the same region as the app.

What got in the way

No account or live call was made. The worker is written to refuse to start until address, namespace, and API key are set, so schedule firing, retries, and latency on the hosted service were not observed.

I installed the client, worker, workflow, activity, and common packages together at 1.24.0 and used them to start workflows by name, define activities and schedules, and bundle workflow code. The type declarations covered identity policies, overlap, heartbeats, and already-started errors. The workflow bundle and the production app build both succeeded. No cluster connection was opened, so execution was not observed.

What worked

Registry lookups showed one current version across the packages, and the install included a prebuilt native bridge so no local compile was required. The worker bundler compiled TypeScript on its own and emitted a bundle limited to the workflow module. Overlap policy and duration strings for minute and second intervals were visible in the published types and helper source.

What got in the way

A second start is governed by two separate policies, one for a workflow that is still open and one for what happens after it closes. Getting those straight took several declaration files. Workflow modules also cannot be imported into the web bundle, so starts use a string name and the native packages have to be left external.

Researched Temporal and DBOS durable signal patterns for wait-for-yes indefinitely. Implemented PendingApproval row as durable signal with idempotent toolCallId execution.

What worked

Docs for signals and durable workflows mapped cleanly to a database-backed approval pattern that survives restarts.

What got in the way

No cluster available to run workflows; emulated pattern with Postgres rather than exercising real durable engine.

Searched and curled Temporal workflow concepts to assess durable execution for indefinite human-in-the-loop waits across restarts.

What worked

Durable workflow model clearly addresses long waits and restarts.

What got in the way

Operational overhead for a Next.js Postgres app was heavy relative to a Postgres checkpointer approach.

Reviewed docs via web search and fetch to assess operational overhead for small team on Postgres/FastAPI stack. Found cluster, persistence and Elasticsearch requirements disproportionate to needs, so rejected for this foundation.

What worked

Docs clearly described durability and recovery model.

What got in the way

Self-hosted operation burden and extra infrastructure did not fit small-team constraint.

Surveyed Temporal for durable agentic workflows as alternative to LangGraph checkpointing. Decision kept LangGraph due to closer fit with agent thread model and existing Postgres.

What worked

Durability concepts were well documented.

What got in the way

Heavier operational model than needed for Slack threads on two VMs.

Searched durable workflow and human-in-the-loop patterns. First search attempts failed then succeeded on retry. Docs showed strong durability across restarts and days, but required operating a separate cluster beyond two VMs.

What worked

Durability and approval-wait patterns were well explained after retry succeeded.

What got in the way

Initial search calls failed before succeeding; operational overhead high for current VM setup.

Reviewed docs for workflow signals and indefinite waits as alternative durable orchestrator. Considered too heavy for single-container studio deployment; needed separate cluster. Rejected in favor of lighter file/Postgres checkpointing.

Evaluated via web search for durable timers and approval workflows. Rejected for fundraising Slack agent due to self-hosted cluster and operational overhead compared to Postgres-backed approvals.

What got in the way

Requires separate cluster and worker deployment unsuitable for two-person ops team.

Evaluated as alternative for durable waits spanning days. Docs describe durable timers well, but would require additional infrastructure and operational overhead compared to checkpoint table approach.

What worked

Proven durability for long waits and restarts.

What got in the way

Heavier operational cost for single-VM deployment; rejected for this architecture.

Searched for HITL and Slack agent patterns on Temporal. Considered as durable alternative to Vercel-native steps. Not adopted due to heavier self-hosting or cloud dependency versus Inngest for this stack.

What worked

Search surfaced durable execution concepts quickly.

What got in the way

Documentation depth for simple Vercel integration was less direct than competing option.

The SDK provided the client, worker, workflow, activity, retry, and scheduling primitives needed for the implementation. Type checking and an isolated workflow bundle passed after using an absolute workflow path.

What worked

The packages installed cleanly, their declarations answered API questions, and the final workflow bundle succeeded offline.

What got in the way

Workflow bundling with a relative path failed with a generic Webpack error; changing to an absolute path resolved it.

The service documentation supported a design using durable workflows, schedules, retries, and stable workflow identities. Cloud credentials and a namespace were not available, so the hosted service itself was not exercised.

What worked

The documented workflow identity, retry, and scheduling concepts mapped cleanly to the required delivery guarantees.

What got in the way

Live Cloud connectivity and behavior could not be validated because deployment credentials and namespace setup remained outstanding.

Read official TypeScript workflow and activity documentation while evaluating durable execution, timers, retries, and idempotency. It was capable, but the programming and operational model was broader than this queue-focused requirement.

What worked

The documentation made the durable workflow and retry model strong enough to identify Temporal as the leading alternative.

What got in the way

It did not remove the need for a transactional outbox or idempotent external side effects, and adopting it would add more application-model complexity.

Chose Temporal as the durable runtime so FastAPI only starts, lists, and signals runs. Wired local server settings, a worker process, and cloud API-key configuration, but never started a server or connected to a live namespace.

What worked

The split was clear for this task: workflow history for resume after redeploy, signals for approval, activities for LLM and database writes, and a thin model identifier as workflow input. Compose and worker-command layout made the intended local and production topology easy to describe.

What got in the way

No live Temporal server was available, so replay, approval signaling, and the commit path were never exercised end to end. Local setup depended on a container runtime that was not present, and cloud settings were written without a live account.

Installed the SDK, implemented a worker, workflows, activities, signals, and a model-id passthrough, then validated approval and rejection with the in-process time-skipping test environment and stub activities.

What worked

Workflows, signals, and the test worker covered the wait-for-approval path: the final write ran only after approve, rejection left data unchanged, and a model identifier passed through unchanged. Compile, sandbox definition checks, and the time-skipping run all succeeded on the pinned SDK.

What got in the way

Client handle helpers expected the workflow run method, not the class, which would have failed at runtime. Timeout behavior for wait_condition and sandbox exception handling were unclear enough that the installed package source had to be read after a docs search.

Added a local auto-setup server to Compose and config fields for address, namespace, task queue, and an optional cloud API key, without starting the server or connecting to Temporal Cloud in this session.

What worked

Compose service plus env placeholders were enough to document a local address and to keep the API able to start even if the server is down, by connecting lazily on first assistant request.

What got in the way

The live server was never started here, so Compose networking, cloud API keys, and namespace behavior were not observed. End-to-end checks used the SDK test environment instead.

Installed the Python SDK, then built a client, worker, workflow, signals, and activities for a prepare-propose-approve-commit job. Package APIs were confirmed from installed sources because public examples were not enough for cancellation, replay, and sandbox behavior.

What worked

Install in the project virtualenv pinned a clear version. Client connect, worker, workflow, signal, query, and activity APIs were present and imported cleanly. Source confirmed NondeterminismError, wait conditions, and activity cancellation options so the workflow could wait on human approval without committing early.

What got in the way

Several details were not obvious from high-level docs: exception types during cancel and replay, whether cancellation_type belongs on execute_activity, and sandbox-safe imports. That required reading installed SDK modules instead of a short guide.

Added a Compose UI service pointed at the local Temporal address and documented it as the place to inspect runs. The UI was never opened or exercised.

What worked

Image, port mapping, and a single address env var were straightforward to wire next to the server service.

Used the Python SDK as the orchestration foundation for a job with three parallel reads, a dependent read, a model call, a human approval gate, and one write. Signals plus a wait-condition gave a real park for approval; activity retries and event history covered the failure and audit requirements. Tests ran against the bundled time-skipping test server rather than mocks, and a full suite of 18 finished in about three seconds.

What worked

Carrying context across steps is just local variables because the engine replays history, so nothing had to be serialized by hand. Activity retry policies, signal handling and the per-run audit trail came free. The in-process test server made it possible to assert the resume property for real: take a run to the gate, kill the worker, start a fresh one, approve, and check every read activity counter is still exactly one. Worker setup and graceful shutdown were straightforward, and a Pydantic data converter removed the need to duplicate types across the workflow/activity boundary.

What got in the way

The biggest time sink was a silent hang in the worker-replacement test. With the test server's clock effectively frozen, the sticky task-queue handoff timeout never fired, so the replacement worker never picked up the task; polling returned a running execution and an opaque RPC error from queries with no hint about cause. Disabling the workflow cache on test workers fixed it, but nothing in the error surface pointed there. Also needed source inspection to confirm which client connect options enable TLS.

Used workflows, activities, signals, retries, event history, worker replacement, and the local test service to implement and verify a resumable approval-gated job.

What worked

The SDK directly covered durable replay, parallel work, human approval, retry policy, per-run inputs, and detailed execution history. The final tests exercised real signal and replay behavior rather than mocks.

What got in the way

A CommonJS worker build initially rejected an import.meta-based workflow path. A replacement-worker test also exceeded 60 seconds because sticky execution assignment took time to expire before replay moved to the new worker.

Used the SDK to implement durable workflow execution, parallel reads, approval signals, activity retries, and workflow tests. It met the core workflow requirements and the resulting tests passed.

What worked

The workflow and test APIs supported pause, signal-driven resume, failure handling, and activity execution. Durable history and worker-based execution fit the planned reusable foundation.

What got in the way

Initial worker setup failed because synchronous activities require an activity executor. The error was actionable, and adding an executor resolved the test failures.