[mghaznav]

Description

Historically, non-fatal errors in Crashlytics were simple enough that passing a few parameters to a helper function sufficed. However, with the added complexity of Crashlytics' asynchronous initialization, we now need to explicitly separate the data collection logic from the disk recording logic to ensure we preserve the correct execution context.

This PR addresses that complexity by introducing a dedicated FIRCLSNonFatalError class. This model records the state of the error at initialization and provides another method to write the error to disk, effectively seperating the 2.

Related Issues & PRs

• Addresses feedback from: Fix: Preserve caller stack trace and timestamp for queued Crashlytics API calls #16126
• Facilitates: [#16044] Crashlytics Error Identity for Non-Fatals #16045. By centralizing the non-fatal error payload into a dedicated object, we are laying the groundwork to easily support modifying the userInfo dictionary before the error is written to disk. The logic to modify the userinfo dict can move to a method within this class instead of being in recordError(error:, userInfo:) in FIRCrashlytics.m and this method should be called in the initializer for this class to update the dict if needed.

Changes Made

• Created the FIRCLSNonFatalError class in Crashlytics/Models/ to act as an immutable state snapshot.
• Updated recordError:userInfo: to initialize this model before entering the async queue, guaranteeing the origin stack trace is preserved regardless of how long initialization takes.

Testing & Verification

• Real Device Testing: Deployed and verified on a physical iOS device to ensure non-fatal payloads are generated and uploaded correctly.
• Unit Tests: All existing and newly affected unit tests are passing successfully.
• Code Quality: Passed the internal linting and formatting checks (./scripts/check.sh).

#no-changelog

[gemini-code-assist]

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

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.

[mghaznav]

/gemini review

[gemini-code-assist]

Code Review

This pull request refactors non-fatal error recording by introducing the FIRCLSNonFatalError class to capture execution context at initialization. Feedback recommends restoring an early return for nil errors in FIRCrashlytics.m to prevent unnecessary processing and explicitly copying properties in the FIRCLSNonFatalError initializer to ensure data integrity and immutability.

[danger-firebase-ios]

	1 Warning
⚠️	Did you forget to add a changelog entry? (Add #no-changelog to the PR description to silence this warning.)

Generated by 🚫 Danger