fix(onboarding): fail fast when EXA_API_KEY is missing#995
Open
vimzh wants to merge 2 commits into
Open
Conversation
…sing The route previously fell back to "x-api-key": process.env.EXA_API_KEY ?? "", so a missing env var produced an outbound call to Exa with an empty key. Exa returned an auth failure, which was then surfaced to the client as a generic 500 "Failed to fetch content from Exa API" — making missing configuration indistinguishable from upstream errors and slowing self-hosted setup. Read EXA_API_KEY once at the top of the handler, log a specific message when it's absent, and return a 500 with a clear "service is not configured" error. The downstream fetch now uses the validated, non-empty key directly.
There was a problem hiding this comment.
Pull request overview
Note
Copilot was unable to run its full agentic suite in this review.
Adds a server-side guard to prevent calling Exa with an empty API key, returning a clean error response when the EXA integration is not configured.
Changes:
- Validates
process.env.EXA_API_KEYand exits early with a 500 when missing. - Reuses the validated API key for the downstream Exa
fetchcall.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Copilot review flagged two things: 1. console.error inside the handler fires on every request when the key is missing, which spams logs and can mask other errors. Moved the read to module scope so the warning fires once at module load. 2. 'Content extraction service is not configured' tells the client a bit too much about deployment state. Reply with a generic 'Content extraction is unavailable' instead, while keeping the detailed reason in the server log. Also bumped the status from 500 to 503 since 'service unavailable due to missing config' is what we are actually telling the client now.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The extract-content route currently uses
process.env.EXA_API_KEY ?? ""as the auth header. Deploying without EXA_API_KEY set sends a request to Exa with an empty key, Exa returns an auth failure, and the client gets back a generic 500 "Failed to fetch content from Exa API". From the outside that looks identical to any upstream error, which makes self-hosted setups frustrating to debug.This reads EXA_API_KEY once at the top of the handler. If it's missing we log a specific message and return a 500 with "Content extraction service is not configured" so the cause is obviously a config issue rather than an upstream hiccup. The downstream fetch then uses the validated key with no fallback.
Kept the status as 500 to stay consistent with the file's existing 500 for upstream errors. 503 could be argued for a misconfig but introducing a new status code felt like scope creep here.