fix(ui): update error parsing to handle standardized AppError responses#273
Conversation
|
Need an answer fast? Review this PR in Change Stack to ask focused questions about the PR or a changed range. Warning Review limit reached
More reviews will be available in 51 minutes and 34 seconds. Learn how PR review limits work. Your organization has run out of usage credits. Purchase more in the billing tab. ⌛ How to resolve this issue?After more reviews become available, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans include higher PR review limits than trial, open-source, and free plans. In all cases, reviews become available again over time. During sustained high-volume PR review activity, CodeRabbit may temporarily slow when the next review becomes available. Please see our Fair Usage Limits Policy for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughThe PR standardizes error message extraction across the web-dashboard. API error handlers in 8 pages and 1 utility now prefer ChangesStandardize error message extraction across web-dashboard
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Possibly related PRs
Suggested labels
Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Actionable comments posted: 1
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
apps/web-dashboard/src/pages/ProjectSettings.jsx (1)
827-831:⚠️ Potential issue | 🟠 Major | ⚡ Quick winGuard
errorMsgtype before calling.includes().At Line 828,
errorMsg.includes(...)can throw whenerr.response?.data?.messageis not a string (e.g., validation object), causing the error handler itself to fail.Proposed fix
- const errorMsg = err.response?.data?.message || err.response?.data?.error || "Failed to update DB config"; - if (errorMsg.includes("whitelist Server IP")) { + const rawMsg = err.response?.data?.message || err.response?.data?.error; + const errorMsg = typeof rawMsg === "string" + ? rawMsg + : (rawMsg?.message || "Failed to update DB config"); + if (typeof errorMsg === "string" && errorMsg.includes("whitelist Server IP")) { toast.error(<div><b>Access Denied!</b><br />{errorMsg}</div>, { duration: 6000 }); } else { toast.error(errorMsg); }🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@apps/web-dashboard/src/pages/ProjectSettings.jsx` around lines 827 - 831, The error handler builds errorMsg from err.response?.data but calls errorMsg.includes(...) without ensuring it's a string; guard the check by verifying typeof errorMsg === "string" before calling .includes (or convert errorMsg to a string via String(...) or JSON.stringify(...) for non-strings), and then call toast.error accordingly; update the block that defines errorMsg and the conditional that checks for the "whitelist Server IP" substring to use this type-safe check so the error handler won't throw when err.response?.data is an object.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@apps/web-dashboard/src/pages/Webhooks.jsx`:
- Around line 146-147: The error payload may be an object/array so normalize it
to a safe string before calling toast.error or rendering; in Webhooks.jsx update
the logic that builds msg (currently using err.response?.data?.message ||
err.response?.data?.error || ...) to coerce non-string values to a readable
string (e.g. if it's an array join items, if it's an object use JSON.stringify
or extract known fields) and use that normalized string for toast.error(msg) and
for rendering testResult.error in JSX so React never receives an object/array
directly.
---
Outside diff comments:
In `@apps/web-dashboard/src/pages/ProjectSettings.jsx`:
- Around line 827-831: The error handler builds errorMsg from err.response?.data
but calls errorMsg.includes(...) without ensuring it's a string; guard the check
by verifying typeof errorMsg === "string" before calling .includes (or convert
errorMsg to a string via String(...) or JSON.stringify(...) for non-strings),
and then call toast.error accordingly; update the block that defines errorMsg
and the conditional that checks for the "whitelist Server IP" substring to use
this type-safe check so the error handler won't throw when err.response?.data is
an object.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: f11737cd-f6fd-4ebe-925a-c78c293ca137
📒 Files selected for processing (9)
apps/web-dashboard/src/pages/AdminCreateRelease.jsxapps/web-dashboard/src/pages/Auth.jsxapps/web-dashboard/src/pages/CreateCollection.jsxapps/web-dashboard/src/pages/CreateProject.jsxapps/web-dashboard/src/pages/OtpVerification.jsxapps/web-dashboard/src/pages/ProjectSettings.jsxapps/web-dashboard/src/pages/Settings.jsxapps/web-dashboard/src/pages/Webhooks.jsxapps/web-dashboard/src/utils/api.js
|
@yash-pouranik , |
yash-pouranik
left a comment
There was a problem hiding this comment.
Everything looks good, Thank you.
🚀 Pull Request Description
I have updated the UI of web-dashboard to handle new modified API
Fixes #272
🛠️ Type of Change
🧪 Testing & Validation
Backend Verification:
npm testin thebackend/directory and all tests passed.Frontend Verification:
npm run lintin thefrontend/directory.📸 Screenshots / Recordings (Optional)
✅ Checklist
Built with ❤️ for urBackend.
Summary by CodeRabbit