Custom logs are not sent for "non-fatal" errors

[phobos2077]

Please fill in the following fields:

Unity editor version: 2019.2.14f1 Firebase Unity SDK version: 6.8.1 Firebase plugins in use (Auth, Database, etc.): Crashlytics Additional SDKs you are using (Facebook, AdMob, etc.): Platform you are using the Unity editor on (Mac, Windows, or Linux): Windows Platform you are targeting (iOS, Android, and/or desktop): Android Scripting Runtime (Mono, and/or IL2CPP): Mono & IL2CPP

Please describe the issue here:

We are using Crashlytics.Log to log custom log messages based on various warnings and errors. These logs show up in the Firebase console for hard-crash issues (such as a forced crash by dereferencing a NULL-pointer). However these logs are absent from the console when I call Crashlytics.LogException which is shown as a "non-critical" issue.

Considering that most bugs in Unity code almost never lead to an actual hard crash, we really need those unhandled exceptions to be treated in the same way as crashes.

Note that custom keys and UserId are shown correctly for hard crashes as well as exceptions.

Please answer the following, if applicable:

Have you been able to reproduce this issue with just the Firebase Unity quickstarts (this GitHub project)?

Yes

What's the issue repro rate? (eg 100%, 1/5 etc)

100%.

[paulinon]

Hi @phobos2077 Could you provide a minimal reproducible example of your project so I could identify the issue? Aside from that, could you provide examples on what non-critical issues are? Thanks!

[phobos2077]

@paulinon In English-US version of a Firebase Console those "non-critical" issues are called "non-fatal". I hope that makes sense. It's very easy to reproduce the issue - just calling Crashlytics.LogException does the trick. Any previous Crashlytics.Log won't show up in the "Logs" tab of the "Session summary" panel. As I've mentioned before, these logs do show up if I force a "real" crash of the app.

[paulinon]

I'm having a hard time trying to reproduce your issue here. The Crashlytics.Log custom messages seem to appear in my Logs tab. Since you mentioned that you made use of the quickstart, could you specify the steps I need to take to reproduce your issue?

[phobos2077]

@paulinon How do you trigger the crash? As I've mentioned already, logs do appear for hard-crashes. It's the "non-fatal" errors that have this issue. Try throwing an unhandled exception or calling Crashlytics.LogException.

[paulinon]

@phobos2077 I made use of the Crashlytics sample in the quickstart. I built the app on an Android device after importing the SDK and placing my google-services.json. The Log message button calls Crashlytics.Log while the Log Caught Exception calls Crashlytics.LogException. The Crashlytics.Log custom messages are seen in my Logs tab while the Crashlytics.LogException messages are not. Could you confirm if something is missing in my procedure? Thanks

[tzmm]

We're seeing this as well, and is proving problematic.

I just ran a test that looked like this:

Crashlytics.Log("Test 0"); throw new System.Exception("Exception number 0"); Crashlytics.Log("Test1"); throw new System.Exception("Exception number 1");

now manually shut down the app, and restart to allow Crashlytics to upload the log (won't upload otherwise).

The attached log with the non-fatal will contain the following: (note that there will be only a single report, for exception 1)

Exception number 0 Test1 Exception number 1

It seems that each successive exception thrown breaks the custom log into a new chunk, and that only the last exception thrown prior to restart is reported, along with its log fragment extending back to the previous exception.

This means that our app could be throwing lots of exceptions, but if they don't kill the app, we'll only ever know about the last one (assuming the user runs the app again).

(Note: the system.exception is hooked to a button in UI, so as to not kill the primary loop in the app when the exception is thrown).

[phobos2077]

In my case it's a bit different - I don't see any logs for exceptions at all, not first not last, never. I'll try to make a minimum repro when I'll have time if you can't reproduce it for some reason.

[paulinon]

Hello, according to my repros, it seems that not all my custom logs are being displayed when you call Crashlytics.Log then Crashlytics.LogException afterwards. I've filed an internal bug report regarding this. I can't provide any timelines for the fix, so I'll leave this open.

[mrichards]

Update from Firebase: It appears there's a console issue that occurs sometimes when multiple identical logged exceptions are logged during the same session, which I believe is what @tzmm has described. We have reproduced that and are looking into it. We've confirmed that the event counts are accurate on the issue list page, and the logged exceptions are being sent to and processed by Crashlytics.

The logged strings (captured via Crashlytics.Log) are associated with the next logged exception or crash ONLY. Subsequent exceptions will not include those logs. This is intended behavior, though due to the console issue I just described, some customers may be experiencing "lost" logs.

I can see how in some cases it would be useful to see the entire log history up to the event. Please let us know if you are interested in adding this as a feature. Note that custom keys & values, set via SetCustomKey, will be persisted across events.

[chkuang-g]

@mrichards Any update from Crashlytics side?

[mrichards]

Crashlytics for Android 18.2.7 (released Jan 2022) included some dramatic efficiency improvements in how we handle custom keys and logs. It did not address the behavior that prevents logs from being visible for the entire session, but the change could resolve the issue of the missing logs.

We recommend updating to the latest version of the Firebase Unity SDK (10.0.1). If the problem persists, please reopen this issue.