WakeOps

Google sign-in started looping back to the login page while the API health check stayed green. The Vercel logs finally showed the real failure: Supabase's session pool had reached its fifteen-client limit. Every serverless instance could create a Prisma client, and reusing one client inside a warm process could not stop multiple processes from holding sessions.

The web deployment moved to Supabase's transaction pooler with a one-connection Prisma limit, while the Prisma client is cached globally inside each warm runtime. That matches the connection model to serverless execution: short requests borrow a pooled connection instead of every function instance trying to own a database session.

A Temporal activity failed because attemptNumber was missing, even though the TypeScript source clearly passed it. The worker imported the workflows package through its compiled dist output, and that output was older than the source. Restarting the worker kept loading the stale bundle, so the failure looked like a data problem instead of a build problem.

The worker's development command now builds the workflows package before it starts. I also treated already-running workflows separately: Temporal preserves their event history, so changing source code cannot rewrite arguments already recorded for an old execution. Stale executions are terminated and new incidents start against the fresh bundle.

Running the Express API and Temporal worker in one Render service looked convenient, but the service became inconsistent under a small memory and CPU budget. The worker bundles workflow code, holds long-lived Temporal and RabbitMQ connections, and runs consumers, while the API needs predictable resources for webhooks, callbacks, and health checks. A failure in either process also brought down the other.

I separated the API from the worker again. Render now serves only HTTP traffic, while the worker runs independently and connects outbound to Temporal Cloud, Supabase, CloudAMQP, and Twilio. There is no worker URL because nothing calls into it; it polls for work and can reconnect without changing any webhook configuration.

The overview counters animated correctly on page load but failed during polling. When call attempts moved from 9 to 10, the UI displayed 09 and stayed there; other increases and decreases appeared unchanged until a manual reload. The polling data was fresh. The animation effect updated the same state listed in its dependency array, so its cleanup ran immediately and cancelled the frame that would have completed the transition.

I replaced the per-digit reset with a stable previous-value-to-next-value transition driven only by the server value. The old and new numbers are separate layers, increases and decreases move in opposite directions, and an internal state update can no longer cancel its own animation. That also removed the temporary leading zero at digit boundaries.