Harden workflow route against sharer enrichment crashes
An async rejection during sharer-name enrichment could crash the Express 4 process rather than return a 500. willchen96 wrapped the route handlers, made the enrichment lookups non-fatal, and replaced a broad `listUsers` call with targeted per-ID fetches.
The root problem is an Express 4 behavior: an async route handler that rejects without a try/catch escapes normal error middleware and can take down the process. The fix wraps the workflow listing route's async handlers and adds route-level error middleware that converts unhandled rejections into 500 responses.
The sharer enrichment path was also made fail-closed. If a profile or email lookup fails, the workflow listing still returns - the enrichment result is advisory. More consequentially, the previous implementation called listUsers which pages through up to a thousand auth records to find sharer identities. The replacement does targeted lookups against only the user IDs actually referenced by the visible workflows. Cost and latency now scale with the request rather than with total account size.
A smaller thread in the same PR standardizes LLM provider error surfaces. Gemini, OpenAI, and Anthropic call sites now raise explicit errors when API keys are missing, before a provider call is attempted. The failure message now names the missing variable rather than propagating an opaque downstream error.
Spotted something wrong? Or know the PR text has fresher detail than the writeup above?