Fix login, voting and item bugs, and move the store to DynamoDB

[VictorShan]

Fixes the reported bugs (sign-in, voting, adding items) and moves the data layer from Turso/SQLite to DynamoDB.

This PR does not deploy cleanly on its own — see Before merging / deploying. A DynamoDB table has to exist and the data has to be copied across.

---

Before merging / deploying

Every step below is required, in this order.

1. Create the table

cp .env.example .env      # then fill in the values below
npm install
npm run ddb:create-table  # idempotent - re-running on an existing table is a no-op

The table is pk (S) / sk (S), on-demand billing. No secondary indexes.

2. Set the environment variables

New, required — the app will not boot without them (src/env.js validates at import time):

Variable	Example	Notes
AWS_REGION	us-east-1	Pick the region closest to where the app runs. This will dominate the latency #54 is about.
DDB_TABLE_NAME	wheel	Whatever you created in step 1.

New, optional:

Variable	Notes
DDB_ENDPOINT	Points at a local DynamoDB. Leave unset in production.

Credentials: in production, prefer the deploy environment's IAM role. Otherwise AWS_ACCESS_KEY_ID / AWS_SECRET_ACCESS_KEY are read by the SDK as usual.

Removed — safe to delete from the deploy environment and from GitHub secrets:

• DATABASE_URL (dead PlanetScale leftover; blocked startup for a database nothing talked to)
• TURSO_DATABASE_URL, TURSO_AUTH_TOKEN — keep these until step 3 is done, then remove. They are optional now and read only by the migration script.

Unchanged: the Clerk and Soketi variables.

3. Copy the existing data across

Run this from a machine that can reach both Turso and DynamoDB, with TURSO_DATABASE_URL and TURSO_AUTH_TOKEN still set:

npm run ddb:migrate-from-turso -- --dry-run   # reports counts, writes nothing
npm run ddb:migrate-from-turso

What it does:

• Keeps old integer item ids as strings, so items keep their identity.
• Normalises the three timestamp formats the SQLite data accumulated into ISO 8601. An unparseable one becomes "never selected" rather than Invalid Date.
• Turns empty-string URLs into absent attributes.
• Parses the webhook body into an object.
• Is repeatable: rows land on the same keys every run, so an interrupted run can just be repeated.

4. IAM

The app's role needs, on that table only:

dynamodb:GetItem, PutItem, UpdateItem, DeleteItem, Query, BatchWriteItem

Running it locally

npm run ddb:local         # local DynamoDB (dynalite) on :4567, own terminal
npm run ddb:create-table  # once
npm run dev

With DDB_ENDPOINT="http://127.0.0.1:4567" in .env. Any values work for the AWS credentials against a local DynamoDB.

---

What changed

DynamoDB migration (#54)

Single table, everything about one wheel in one partition:

pk = LOBBY#<cuid>
sk = LOBBY                    the wheel: name, description, webhook, timestamps
   | ITEM#<itemId>            one row per option
   | LOG#<timestamp>#<rand>   selection history

The sort keys are ordered so sk < "LOG#" returns the wheel and every item on it in one query, stopping before the log (read separately, capped). src/server/db/lobbyStore.ts is the only module that builds a key.

On the load times in #54: the lobby page needed a relational read plus a table-wide UPDATE that ran before it and blocked the response. It is now one query, with the lastReadAt write moved off the response path — fire-and-forget, and only when the stored value is already stale. That is a structural improvement; I have no production before/after numbers, since the only measurements available here were a local SQLite file against a local DynamoDB. Worth timing after deploy.

Things the old store could not do:

• Votes apply with ADD plus a ConditionExpression cap. The old read-modify-write dropped one of two votes cast at the same moment, and SQLite had no atomic equivalent. Tested with 10 concurrent votes — all 10 land.
• createLobby claims a cuid with attribute_not_exists(pk) instead of check-then-write, so two people generating the same cuid cannot both win it.

Item ids are cuid2 strings now, not autoincrement integers: DynamoDB has no sequence, and a per-lobby counter would add a round trip to every add. Three client call sites moved from number to string.

Drizzle, drizzle-kit and the SQLite schema are gone. @libsql/client stays as a dev dependency for the migration script alone.

Not included: TTL on rows. It would auto-expire old wheels, but per-row TTL deletes items out from under an active wheel unless every read refreshes the whole partition. The 7-day reclaim-on-collision behaviour carries over unchanged instead.

Bug fixes

Found by running the app against a local database and driving it in a browser. Each was reproduced before being fixed.

Issue	Problem	Cause
#68	Every mutation returned 500 when Soketi was down — item was saved, user saw an error	await PusherServer.trigger unguarded after the write
#69	Log panel always empty	selectItem wrote its log after the broadcast, so a broadcast failure skipped it
#70	"Internal server error" instead of a sign-in prompt	isAuthed threw a bare Error → 500, not 401
#71	Signing in dropped you on the home page, losing the wheel's URL	redirect-mode SignInButton, no afterSignInUrl
#72	Reading one wheel restamped last_read_at on every lobby in the database	missing .where()
#73	Most-downvoted item listed first	ascending sort
#74	Votes lost when two people voted at once; scores unbounded	read-modify-write in JS
#75	Downvotes distorted every other item's odds; wheel could render blank	weights measured against the lobby minimum; NaN/0 weights poisoned every slice
#76	New items and votes invisible until a realtime event arrived	nothing invalidated the query cache; router.refresh() does not touch a client useQuery
#77	Blank URL stored as "", which then made the item uneditable	addItem did not validate URLs, updateItem rejected ""
#78	createLobby could navigate to /undefined; recycled cuid inherited old logs	retry loop fell through returning undefined
#79	Log showed the ten oldest entries; error toast fired from the render path	limit with no orderBy
#80	Lobby settings never showed the saved webhook	defaultValues seeded from a still-loading query
#81	Startup required a DATABASE_URL nothing used	PlanetScale leftover
#82	A Clerk hiccup took down public reads, rendering as an empty wheel	getAuth throwing failed the whole batched request

Sign-in and sign-up are modals that return to the page they started from, and signed-out visitors are told what needs an account instead of meeting buttons that 401. Viewing a wheel, its items and its log stays public.

Testing

• tests/lobbyStore.spec.ts — 12 tests over every DynamoDB access pattern, against a local DynamoDB the tests start themselves. Its own Playwright project (npx playwright test --project=store), so it runs once rather than per browser, and CI needs no AWS account.
• Browser pass against a local DynamoDB: add → vote → select → spin landing on an item → log, with realtime deliberately offline. No page errors.
• Migration exercised on representative legacy rows (all three timestamp formats, empty-string URLs, JSON webhook body), read back through the API, and re-run to confirm it is repeatable.
• npm run lint, tsc --noEmit and npm run build are clean.

Not run here: the existing browser tests against real Clerk credentials. Signed-in UI paths were verified through a temporary local Clerk stub, which is not part of this branch; signed-out paths were verified for real.

Follow-up worth considering

One vote per user, per item. It is the other honest reading of "the voting is bad" — right now one person can click + up to the cap. It needs its own item type in the table (VOTE#<userId>), so I left it out of a PR that is already moving the database.

---

Generated by Claude Code

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
wheel	Error		Aug 20, 2026 12:45am