Skip to content

fix(demo): flag a seeded world an app emulator no longer holds - #21

Merged
tela merged 2 commits into
mainfrom
feat/demo-readiness
Nov 10, 2026
Merged

tela merged 2 commits into
mainfrom
feat/demo-readiness

Conversation

@tela

@tela tela commented Nov 10, 2026

Copy link
Copy Markdown
Contributor

Motivation

The readiness strip reported Ready from health checks alone. Plaid and Xero keep their data in memory, so after a restart they answer health but have lost the access token and invoices the demo saved at seeding. The page showed three green Ready badges, and the first click failed at Connect with INVALID_ACCESS_TOKEN. This happens whenever an app emulator restarts between a rehearsal and a live demo.

Changes

  • world.Verify checks that each app emulator still holds what seeding saved: the connected Stripe account, the Plaid access token (/item/get) and the Xero invoice count. Only a definite 4xx counts as stale. A timeout, refused connection or 5xx is not called stale, because the health check already reports those.
  • GET /api/status gains stale and no longer reports ready while any vendor is stale.
  • The UI shows an Out of date badge on the vendor, names it in the readiness card and beside the disabled Apply button, and says to press Reset.
  • The troubleshooting guide gets a row for it.
  • The Plaid sandbox credentials move to constants so the seeder and the check send the same ones.

Tests

make vet                      # clean
make test                     # ok, every module
make check-kits check-samples # ok
cd web && pnpm install --frozen-lockfile
cd web/demos/acme-commerce-lenders
pnpm type-check               # clean
pnpm exec biome check .       # clean
pnpm exec vitest run          # 9 files, 46 tests passed

New tests: world/verify_test.go (holds, missing Plaid token, missing Stripe account, short Xero invoices, and no report for a 500 or a refused connection), TestAStaleWorldIsNotReadyUntilItIsReset in internal/api, and a DemoPage test for the Out of date state.

Against real app emulators (WonderTwin twin-stripe, twin-plaid, twin-xero on throwaway ports): after Reset the status is ready: true. After restarting twin-plaid it is ready: false, stale: [plaid] with the Plaid INVALID_ACCESS_TOKEN answer in the reason. After Reset again it is ready: true.

Related

Part of making the demo easy to run on a laptop. Next: doctor, a one-command start, and pinned emulator versions.

tela added 2 commits November 9, 2026 19:55
Status reported ready from health checks alone. A restarted Plaid or
Xero answers health but has lost the saved access token and invoices,
so the page showed three green Ready badges over a run that failed at
Connect with INVALID_ACCESS_TOKEN. Check the saved Stripe account,
Plaid token and Xero invoice count, and report a vendor that answers
with a definite 4xx as stale. A timeout or 5xx is not called stale.
Show an Out of date badge on the vendor, name it in the readiness card
and next to the disabled Apply button, and tell the presenter to press
Reset. Add the matching row to the troubleshooting guide.
@tela
tela merged commit 14c682f into main Nov 10, 2026
2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant