fix: show error feedback in Import Map dialog and standardize API error responses#333
fix: show error feedback in Import Map dialog and standardize API error responses#333
Conversation
…or responses The Import Map dialog silently swallowed errors (server offline, proxy 413, bad zip) — the progress bar would just disappear with no feedback. Now errors are displayed inline in the dialog footer. Backend: convert importMapToolZip from raw http.HandlerFunc to idiomatic fuego handler. Add Detail field to all fuego error returns across all endpoints so error messages are serialized to the client (Err is json:"-" and was invisible). Frontend: parse fuego's detail field in XHR error responses, display error banner in ImportDialog with specific message for 413 and generic fallback.
Coverage Report for ui
File Coverage
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Summary of ChangesHello, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request significantly enhances the user experience for importing maps by providing clear, immediate error feedback directly within the UI. Concurrently, it standardizes the backend's API error responses to include more descriptive details, ensuring that the UI can present meaningful messages for various failure conditions, from network issues to invalid file formats. This change improves debuggability and user guidance without altering core functionality. Highlights
Changelog
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
There was a problem hiding this comment.
Code Review
This pull request refactors the importMapToolZip handler to use idiomatic fuego patterns and standardizes API error responses by adding a Detail field, aiming to provide clearer user feedback. However, these changes introduce a systemic security risk by exposing internal error details to the client. A potential access control flaw was also identified in the MapTool event stream.
…d info leaks InternalServerError and NotFoundError now use static, descriptive detail messages instead of err.Error() which could expose file paths or DB internals. BadRequestError keeps err.Error() since those are input validation messages (strconv parse errors, JSON decode errors) that help the user fix their request.
Merging this branch will increase overall coverage
Coverage by fileChanged files (no unit tests)
Please note that the "Total", "Covered", and "Missed" counts above refer to code statements instead of lines of code. The value in brackets refers to the test coverage of that file in the old version of the code. Changed unit test files
|
Summary
importMapToolZipfrom rawhttp.HandlerFuncto idiomatic fuego handler (ContextNoBodysignature), removed unusedwriteJSONErrorhelperDetailfield to fuego error returns — previously onlyErrwas set, which isjson:"-"and never reached the clientTest plan
go test ./internal/server/)npx tsc --noEmit)npx vitest run dialogs.test.tsx)client_max_body_size→ error banner shows proxy upload limit message