fix(dashboard): suppress favorite status error toast on 404#41402
Open
sadpandajoe wants to merge 3 commits into
Open
fix(dashboard): suppress favorite status error toast on 404#41402sadpandajoe wants to merge 3 commits into
sadpandajoe wants to merge 3 commits into
Conversation
When a non-owner user opens a draft dashboard by direct URL, the favorite_status API correctly returns 404 (draft visibility is owner/admin-only). The frontend was treating all errors the same and surfacing a danger toast. A 404 here means "favorite status isn't available for this user" and should be swallowed silently. This also covers the case where a dashboard is deleted after navigation. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #41402 +/- ##
=======================================
Coverage 64.37% 64.37%
=======================================
Files 2653 2653
Lines 145152 145154 +2
Branches 33491 33492 +1
=======================================
+ Hits 93446 93448 +2
Misses 50014 50014
Partials 1692 1692
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
Replace the getClientErrorObject async call with an instanceof Response type guard. This is type-safe (Response.status is a typed property) and matches the runtime rejection shape from SupersetClient's parseResponse. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
✅ Deploy Preview for superset-docs-preview ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
Contributor
There was a problem hiding this comment.
Pull request overview
Suppresses the “favorite status” danger toast when the favorite_status API call returns a 404 (e.g., non-owner viewing a draft dashboard via direct URL, or a dashboard being deleted during navigation), while preserving the existing guard that prevents stale-error toasts after navigation.
Changes:
- Update
fetchFaveStarto silently swallow 404 responses instead of dispatching a danger toast. - Add a unit test ensuring no toast is dispatched for a 404 when the dashboard ID still matches.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
| superset-frontend/src/dashboard/actions/dashboardState.ts | Swallows 404 errors in fetchFaveStar to avoid alarming users when favorite status is legitimately unavailable. |
| superset-frontend/src/dashboard/actions/dashboardState.test.ts | Adds regression coverage to confirm 404s do not dispatch a danger toast. |
Ensures a 500 Response error still dispatches the danger toast, preventing a future mutation from silently swallowing all Response errors by dropping the status === 404 condition. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
dosubot
Bot
added
change:frontend
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.
SUMMARY
When a non-owner user opens a draft dashboard by direct URL, the
GET /api/v1/dashboard/favorite_status/endpoint correctly returns 404 (draft dashboard visibility is owner/admin-only at the API layer). However,fetchFaveStar's.catchhandler treated every error uniformly and surfaced a danger toast: "There was an issue fetching the favorite status of this dashboard."A 404 here means "favorite status isn't available to this user" — it is not an error worth alarming the user about. This also covers the case where a dashboard is deleted after navigation began.
Fix: In
fetchFaveStar's.catch, use the already-importedgetClientErrorObjecthelper to extract the response status. Ifstatus === 404, return silently instead of dispatching the danger toast. Non-404 errors (network failures, 500s) continue to toast when the dashboard ID still matches, preserving the existingcurrentId === idrace-condition guard.Related: #33007 (closed unmerged) addressed the same symptom for the deleted-dashboard case. This PR covers both the draft-non-owner case and the deleted case with the same 404 check.
BEFORE/AFTER SCREENSHOTS OR ANIMATED GIF
Before: Non-owner loads a draft dashboard → red danger toast appears on load.
After: No toast. The 404 from
favorite_statusis silently swallowed.TESTING INSTRUCTIONS
Automated:
npm run test -- src/dashboard/actions/dashboardState.test.ts— the new test'does NOT dispatch a danger toast on 404 error when the dashboard ID still matches'covers the fix, and the existing'dispatches a danger toast on error when the dashboard ID still matches'(non-404) confirms non-404 errors still toast.ADDITIONAL INFORMATION