🥅 app: report expected errors as sentry warnings

[cruzdanilo]

---

Summary by CodeRabbit

• Bug Fixes
  • Improved error classification and reporting throughout the application. Expected errors are now reported as warnings instead of being suppressed, providing better visibility into application health and user interactions while appropriately handling authentication and user-initiated actions.

[changeset-bot]

🦋 Changeset detected

Latest commit: b6afa4e

The changes in this PR will be included in the next version bump.

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[coderabbitai]

Warning

Rate limit exceeded

@cruzdanilo has exceeded the limit for the number of commits that can be reviewed per hour. Please wait 13 minutes and 12 seconds before requesting another review.

⌛ How to resolve this issue?

After the wait time has elapsed, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

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 have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout.

Please see our FAQ for further information.

Walkthrough

Refactors error handling to report expected errors as Sentry warnings instead of dropping them. Introduces a new action() helper function and updates error classification from "expected" to "known" across the codebase, affecting QueryClient configuration, Sentry integration, and error reporting utilities.

Changes

Cohort / File(s)	Summary
Error Classification & Reporting System src/utils/reportError.ts, src/app/_layout.tsx	Refactors error classification naming (expected → known) and adds classifyError() public helper. Changes Sentry error handling from dropping known errors to setting level to "warning" with fingerprint propagation. Unified error capture flow replaces conditional branching.
Query Client Configuration src/utils/queryClient.ts, src/utils/server.ts	Introduces action() function returning "warn", "drop", or undefined for error routing. Updates React Query meta from suppressError to dropError and warnError. Modifies onError handler and retry logic for kyc/status queries to use new action-based control flow.
Auth Hook Integration src/utils/useAuth.ts	Adds conditional error reporting via reportError() with warning level for biometric failures, unhandled auth errors, and backup eligibility checks. Uses classifyError() to identify and exclude user-cancelled flows from warnings.
Release Configuration .changeset/silent-lemons-applaud.md	Adds changeset file indicating patch release for @exactly/mobile with note: "🥅 report expected errors as sentry warnings".

Sequence Diagram

sequenceDiagram
    participant App as App (Error Handler)
    participant Classify as Error Classifier
    participant QC as QueryClient
    participant Action as Action Evaluator
    participant Sentry as Sentry

    App->>Classify: parseError(error)
    Classify-->>App: {known, fingerprint, ...}
    App->>QC: onError handler triggered
    QC->>Action: action(error)
    alt action returns "drop"
        Action-->>QC: "drop"
        QC->>QC: skipError via dropError meta
    else action returns "warn"
        Action-->>QC: "warn"
        QC->>Sentry: report with level: warning
    else action returns undefined
        Action-->>QC: undefined
        QC->>Sentry: report with default level
    end
    Sentry->>Sentry: capture with fingerprint

Loading

Estimated code review effort

🎯 4 (Complex) | ⏱️ ~45 minutes

Possibly related PRs

• 🥅 app: handle and suppress expected errors #795: Modifies error classification and Sentry reporting flow in reportError.ts and useAuth.ts to treat expected errors as warnings instead of suppression.
• 🥅 app: globally suppress expected kyc api errors #784: Updates queryClient.ts error handling to centralize the expected error-suppression logic, which this PR evolves into an action/drop/warn model.
• 🥅 app: fingerprint api errors with status #787: Adds status-based APIError fingerprinting in reportError.ts, complementing the classification system refactored in this PR.

Suggested reviewers

• dieguezguille
• franm91

🚥 Pre-merge checks | ✅ 2

✅ Passed checks (2 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title accurately describes the main objective of the changeset: refactoring error handling to report expected/known errors as Sentry warnings instead of filtering them out.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch catch

---

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.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[gemini-code-assist]

Summary of Changes

Hello @cruzdanilo, I'm Gemini Code Assist¹! 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 refines the application's error reporting strategy by changing how "expected" errors are handled. Previously, these errors were often suppressed or ignored in Sentry. Now, they are explicitly reported as warnings, providing better visibility into common, non-critical issues without escalating them to critical error alerts. This change helps maintain a clearer picture of application health and user experience.

Highlights

• Sentry Error Reporting: Expected errors are now reported as Sentry warnings instead of being suppressed, providing better visibility into non-critical issues.
• App Layout Sentry Integration: The Sentry beforeSend hook in the app layout now explicitly sets the event level to 'warning' for errors classified as expected.
• Query Client Error Handling: Error handling in the QueryCache was updated to report expected errors as warnings via reportError instead of simply returning.
• Centralized Error Reporting Utility: The reportError utility function was modified to set the Sentry scope level to 'warning' if an error is classified as expected.
• Authentication Error Visibility: Specific biometric and authentication cancellation errors in useAuth are now explicitly reported as warnings to Sentry.

Changelog

• .changeset/silent-lemons-applaud.md
  • Added a new changeset file for the @exactly/mobile package, documenting the change to report expected errors as Sentry warnings.
• src/app/_layout.tsx
  • Modified the Sentry beforeSend hook to set the event.level to "warning" for errors classified as expected, instead of returning null.
• src/utils/queryClient.ts
  • Updated the onError callback within the QueryCache to call reportError with level: "warning" for errors that are either suppressed by query.meta.suppressError or classified as expected via the expected utility function.
• src/utils/reportError.ts
  • Refactored the reportError function to remove the early return for classification.expected.
  • Introduced logic within the withScope callback to set the Sentry scope level to "warning" if classification.expected is true.
• src/utils/useAuth.ts
  • Added reportError(error, { level: "warning" }) calls for biometric errors (ERR_BIOMETRIC or message includes "Biometrics must be enabled").
  • Added reportError(error, { level: "warning" }) calls for authentication cancellation errors (isAuthExpected(error) || error instanceof UserRejectedRequestError).

Activity

• No activity found for this pull request.

Using Gemini Code Assist

The 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 /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

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 .gemini/ folder in the base of the repository. Detailed instructions can be found here.

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

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

The pull request effectively implements the change to report expected errors as Sentry warnings instead of suppressing them entirely. The reportError utility function has been refactored to correctly classify errors and set the Sentry event level to 'warning' when an error is expected. The modifications in _layout.tsx, queryClient.ts, and useAuth.ts consistently apply this new error handling strategy. The changes are well-implemented and align with the stated goal of the pull request.

[sentry]

Codecov Report

❌ Patch coverage is 68.08511% with 15 lines in your changes missing coverage. Please review.
✅ Project coverage is 69.34%. Comparing base (8ee6800) to head (b6afa4e).
⚠️ Report is 1 commits behind head on main.
✅ All tests successful. No failed tests found.

Files with missing lines	Patch %	Lines
src/utils/useAuth.ts	0.00%	9 Missing ⚠️
src/utils/server.ts	0.00%	6 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #801      +/-   ##
==========================================
- Coverage   69.76%   69.34%   -0.42%     
==========================================
  Files         208      208              
  Lines        7471     7096     -375     
  Branches     2394     2264     -130     
==========================================
- Hits         5212     4921     -291     
+ Misses       2043     1991      -52     
+ Partials      216      184      -32     

Flag	Coverage Δ
e2e	69.30% <68.08%> (-0.43%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.