test(ShareSheet-error-resilience): ShareSheet hydration stability, exception safety and error fallbacks#3566
Merged
JhaSourav07 merged 1 commit intoJun 4, 2026
Conversation
Contributor
|
@Subhooo5 is attempting to deploy a commit to the jhasourav07's projects Team on Vercel. A member of the Team first needs to authorize it. |
Contributor
Author
|
Hey @JhaSourav07 Test added successfully. All existing tests pass locally. Feel free to review, add necessary labels and merge it. 🫂🚀 |
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.
Description
Fixes #2618
components/dashboard/ShareSheet.error-resilience.test.tsxwith a localErrorBoundaryclass component that acts as the "localized boundary element" — catches render-phase exceptions, logs toconsole.error(dev telemetry), and renders a named recovery UI with a reset buttonmockUseShareActionsis exposed at module scope so individual tests can override it to throwTest 1:isOpen=falseproduces zero DOM nodes — validates the null-render hydration path with no client/server mismatch riskTest 2:isOpen=truemounts cleanly with all key structural elements present — confirms stable baseline hydrationTest 3:useShareActionsthrowing during render is caught byErrorBoundary; fallback UI renders,console.erroris called with the exception (telemetry assertion), and aTry againreset button is present on the recovery panelTest 4:window.openstubbed to throw simulates a browser policy block; component tree remains mounted and interactive after the event-handler error (React 18 does not unmount on event errors)Test 5:exportDatawith all-zero/empty values renders without throwing and shows no error fallback — confirms defensive prop handlingPillar
Checklist before requesting a review:
CONTRIBUTING.mdfile.localhost:3000/api/streak?user=YOUR_USERNAME).npm run formatandnpm run lintlocally and resolved all errors.