Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[FR]: Modify custom keys behavior to be consistent with Android #13153

Open
luqas11 opened this issue Jun 18, 2024 · 1 comment
Open

[FR]: Modify custom keys behavior to be consistent with Android #13153

luqas11 opened this issue Jun 18, 2024 · 1 comment

Comments

@luqas11
Copy link

luqas11 commented Jun 18, 2024

Description

If multiple non fatal reports are sent, and different custom key values are set between them, all the reports have the the values of the last one.
This behavior is not consistent with the Android SDK, where each report is sent with the custom key values set at the moment of calling the recordException method.

For example, if I do the following sequence:

  1. Set key some_attribute with value value1
  2. Send a non-fatal exception with the recordError method
  3. Set key some_attribute with value value2
  4. Send another non-fatal exception with the recordError method
  5. Restart the app

On iOS, both non-fatal errors are shown in the Crashlytics dashboard with the some_attribute key set to value2.
On Android, the first and the second non-fatal errors are shown in the Crashlytics dashboard with the some_attribute key set to value1 and value2 respectively.

From my perspective, having different behaviors between platforms adds complexity to the error reporting implementations and while doing error analysis. Before the FR, I created an issue about this, including detailed code examples and screenshots. I got the confirmation that the current behavior is intentional, and that I should report it as a feature request.

Is a behavior unification viable?

API Proposal

No response

Firebase Product(s)

Crashlytics

@google-oss-bot
Copy link

I couldn't figure out how to label this issue, so I've labeled it for a human to triage. Hang tight.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants