Temporal / Local reservation evaluation
Remember the workflow. Verify the booking.
Temporal remembers workflow progress and retries activities. AnswerUp checks the external business effect and whether the current caller may receive its confirmation. Try both with a local restaurant example that makes no real booking and needs no model. No Temporal Cloud account required. AnswerUp SDK downloads require approved private-preview access.
Run the local example
Use Linux x86-64, Node 22.23.2, npm 10.9.8 and Temporal CLI 1.9.1 with embedded Server 1.32.0. The five Temporal TypeScript packages are pinned at 1.25.0; other platforms and versions have not been verified. You need a writable temporary directory and free loopback port 17233.
The source includes README, setup tools, workflow, activities, protected host, Apache 2.0 LICENSE and NOTICE. It contains no private SDK archives. Obtain Core 1.0.0-rc.1, Runtime 0.2.0-preview.5 and Actions 0.2.0-preview.8 through Package access, and keep the three .tgz files together.
Extract the source into an empty directory:
mkdir temporal-source
tar -xzf temporal-source.tar.gz -C temporal-source
cd temporal-sourceInstall Temporal CLI 1.9.1 if needed
Use these accepted commands if the matching binary is not already on your PATH:
mkdir -p /tmp/answerup-temporal-cli
curl -fL https://github.com/temporalio/cli/releases/download/v1.9.1/temporal_cli_1.9.1_linux_amd64.tar.gz -o /tmp/answerup-temporal-cli/cli.tar.gz
echo '09a0326a51db84d02735e53542b9ebd8c4758daf47482a9ab0abce15844e60d5 /tmp/answerup-temporal-cli/cli.tar.gz' | sha256sum -c -
tar -xzf /tmp/answerup-temporal-cli/cli.tar.gz -C /tmp/answerup-temporal-cliFrom the extracted directory, use one terminal and two commands. Replace the SDK directory with yours; omit TEMPORAL_CLI=... when the matching CLI is on PATH.
npm run setup -- /path/to/authorized-sdk
TEMPORAL_CLI=/tmp/answerup-temporal-cli/temporal npm startSetup checks the three SDK digests before copying them and runs the locked npm install with lifecycle scripts disabled. Installation needs registry access or a populated npm cache. No Python, manual build or live credentials are required. See the included README.md for the complete accepted instructions.
Workflow progress and business evidence
The workflow and activities call an application-owned protected host using a stable request ID. Temporal may retry the activity, but only the host can dispatch the provider or reconcile the original effect. Workflow completion and activity status are orchestration records; neither proves a booking or permits a customer confirmation.
The accepted evaluation covers a normal verified booking, a lost response with UNKNOWN and no confirmation, verifier-only reconciliation, graceful worker restart and authorized replay. Revoked result access intentionally fails the third workflow: that is a passing denial check. Expected output is 2 provider mutations, 5 verifier reads and 0 recovery redispatches, followed by PASS.
The host checks current access before releasing wording. Your application still supplies trusted authentication, authorization, provider execution, authoritative verification, protected storage and customer delivery. Temporal history access and retention remain separate responsibilities. See provider and verifier responsibilities and UNKNOWN reconciliation.
Understand the recovery boundary
The Temporal dev server saves workflow history in a temporary database. The AnswerUp host keeps operation state in a separate temporary file, and the synthetic provider keeps business truth in memory. The demonstration restarts only the Temporal worker while the host and provider remain alive. Restarting the whole demo starts fresh; retained files are diagnostic material, not a supported restore procedure.
This is a synthetic-provider and synthetic-authentication example with one trusted file writer and graceful worker restart. It does not establish production certification, arbitrary-crash safety, multi-writer durability or exactly-once external execution. Do not clear stale host locks and redispatch blindly. Result authorization protects host release, not atomic delivery over a network.
The wrapper starts its own local server and bounds evaluation to 120 seconds after readiness. Normal completion and shutdown were checked; timeout, interrupt and abrupt child-death cleanup races were not fully exercised. Synthetic temporary state and logs are retained for diagnosis. A hard termination may require separate process cleanup.
For the same reservation scenario over HTTP, see the Restaurant HTTP quickstart. Source licensing does not change the separate SDK entitlement or dependency terms described in LICENSE and NOTICE.