String metadata is being trimmed to 63 characters (native crashes)

[pavlos-lyft]

Describe the bug

If I report a string metadata which length is larger than 63 characters, it is being cropped for native crash events.
For example, if I want to report this string as metadata:
123456789_123456789_123456789_123456789_123456789_123456789_123456789_
The following value will be displayed in Bugsnag dashboard (which length is 63 chars):
123456789_123456789_123456789_123456789_123456789_123456789_123

What's interesting is that if I set this metadata in addOnSend function (on next session after crash) using event.addMetadata - the string will be reported correctly without any trimming. Probably, the issue might be related to a metadata caching mechanism.

Steps to reproduce

I've added this use case to a simple application from this issue.
It is based on Bugsnag sample application.

1. Simulate native crash
2. Run the app
3. Check the dashboard - TEST_TAB tab.
4. longString is trimmed but anotherLongString is not trimmed (because it's set in addOnSend callback).

All the important code could be found in ExampleApplication.kt file. Here is the metadata that is being trimmed and here is the metadata that is being reported correctly (due to being set in addOnSend callback)

Environment

• Android version: 12
• Bugsnag version: 5.20.0
• Emulator or physical device: Physical device

Example Repo

https://github.com/pavlos-lyft/bugsnag-android-issue-demo

[xljones]

Hey @pavlos-lyft 👋 , thanks for the issue and reproduction example. I can confirm we're seeing the same as yourself. I'm afraid this is a known issue. Strings set in the NDK layer are limited to a maximum of 64 characters, but due to the inclusion of a null terminator, the string will be truncated to 63 characters.

The reason that you see the string with length >= 64 characters when added in the addOnSend callback (available from https://github.com/bugsnag/bugsnag-android/releases/tag/v5.16.0 onwards) is because this runs in the JVM layer, it allows for an unlimited string to be added, so this would be a suitable workaround if the value you're looking to add is available on relaunch of the application, you can augment the report in the JVM layer.

This is an issue that would be resolved with fixes to #1625, so I'm closing this issue in favour of that one as it's already linked to our internal roadmap :)