willchen96 keeps one shared workflow from taking down the whole backend

A single shared workflow could crash the entire service; now the listing screen fails gracefully instead.

infrastructureworkflow

When someone shares a saved workflow with colleagues, the project has to look up who shared it before showing the list. willchen96 found that if that lookup went wrong, it didn't just show an error - it could bring down the entire backend. The fix makes the screen fail soft: if a sharer's name or email can't be resolved, the workflow list still loads. It also stops the screen from scanning every account in the system just to identify a handful of sharers, looking up only the ones it actually needs - which trims both errors and running cost as the user base grows.

A second pass tidies how the project talks to its AI engines - Gemini, OpenAI and Anthropic, the large language models behind the product. A missing API key now produces a clear, named error rather than an opaque one.

So what Anyone running Mike in production should care: this is the line between a tidy error message and an outage.

View this fork on GitHub →

Spotted something wrong? Or know the PR text has fresher detail than the writeup above?

Commits in this thread

2 commits from willchen96/mike, oldest first. Source extracted verbatim from the harvested git log.

SHA Subject Author Date
a2368a74 refactor: enhance error handling and streamline API key management in LLM modules willchen96 2026-05-14 ↗ GitHub
9e7046d4 Merge pull request #132 from willchen96/project-page-deployment-fixes cosimoastrada 2026-05-14 ↗ GitHub
refactor: enhance error handling and streamline API key management in LLM modules

Capture this thread into my fork

Download a single Markdown prompt that tells Claude how to port every commit above into your working tree — adapting paths and structure to match your repo. Run it via claude -p < capture-thread-478.md from inside the repo you want the changes in.

⬇ Download capture-thread-478.md