fix: initialize default production LLM provider client (#393)#405
Conversation
…o fix/landing-page-refinement
…finement # Conflicts: # src/app/(app)/leaderboard/page.tsx # src/app/docs/page.tsx
|
@yush-1018 is attempting to deploy a commit to the codersogs-3057's projects Team on Vercel. A member of the Team first needs to authorize it. |
Ayush-Patel-56
left a comment
There was a problem hiding this comment.
Two things before merging: the beta-pill removal in LandingPage.tsx looks like leftover from branch reuse, not part of this fix, can you drop that hunk? Also package-lock.json has a bunch of unrelated peer: true noise across existing deps, probably an npm version mismatch - worth regenerating cleanly. The LLM fallback logic itself is correct.
51c1611 to
18766fe
Compare
jakharmonika364
left a comment
There was a problem hiding this comment.
The minor suggestion about reading GROQ_API_KEY lazily (for deterministic testing) wasn't addressed, but that was a non-blocking nice-to-have, not a requirement.
jakharmonika364
left a comment
There was a problem hiding this comment.
Scope is clean now, just the LLM fix. Approving.
Currently,
pickProvider()only returns a mock override set up in our tests, and there is no default client configured for production. Because of this, any background sweeps or classifications that triggerllmCallimmediately fail with anllm_unavailableerror, even when the API keys are configured.Fixes #393
I've initialized the default production LLM client in the router to load using the configured environment variables, and updated
pickProvider()to fall back to it when no test override is present. I also added cleanup in the test suite to prevent mock leaks.All typechecks and unit tests are passing!