-
Notifications
You must be signed in to change notification settings - Fork 18
fix: improve api error messages #176
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull Request Overview
This PR improves the API error messaging in the atlas client by refining the error detail extraction and formatting.
- Introduces an additional parameter (body) to capture detailed API errors.
- Refactors the static error construction method to handle both JSON and text responses gracefully.
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
src/common/atlas/apiClientError.ts
Outdated
try { | ||
text = await response.text(); | ||
} catch { | ||
text = ""; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should we set to something like "couldn't fetch error" or "unknown error" too
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok
src/common/atlas/apiClientError.ts
Outdated
private constructor( | ||
message: string, | ||
public readonly response?: Response, | ||
public readonly body?: ApiError |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is there a benefit to us storing the body?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Getting the ApiError model gives us insight into backend error codes, some tools might require an if/else depending on the backend error code.
Looks good but I agree we should hold off from merging/releasing for the time being like with #161 as it's not super critical yet. |
@gagik I think this change fixes type errors from apiClient |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice
* main: (40 commits) chore: add more details for some api errors (#219) fix: use ejson parsing for stdio messages (#218) docs: improve getting started experience (#217) feat: support flex clusters to atlas tools (#182) chore: enforce access list (#214) feat: add back the connect tool (#210) Update connection string app name if not present (#199) chore: update docs with more Service Accounts mentions (#209) chore(deps-dev): bump eslint-plugin-prettier from 5.2.6 to 5.4.0 (#205) chore(deps-dev): bump @types/node from 22.15.3 to 22.15.9 (#204) chore(deps-dev): bump typescript-eslint from 8.31.1 to 8.32.0 (#206) chore(deps-dev): bump eslint from 9.25.1 to 9.26.0 (#207) chore: add recommended extensions and settings (#200) fix: fork checks (#194) docs: correct the link for VSCode's MCP usage (#186) chore: switch to a matrix for forks (#191) chore: skip Atlas Tests and don't track coverage for fork contributions (#188) fix: db user test error (#187) fix: improve api error messages (#176) chore: update quickstart with mcpServers (#185) ...
No description provided.