Fix crashes for extremely long messages with no line breaks

[jmartinesp]

Type of change

• Feature
• Bugfix
• Technical
• Other :

Content

• Adds a max safe length for room list's last message and message summaries.

Motivation and context

Fixes #2105 .

This can affect the rendering of the timeline too, but I'm not sure about how to handle this. Should we hard truncate them at N length? Should we look for the first \n char and if it's > N truncate it them? Should we add some suffix to the end of the message to make sure users understand it's been truncated?

Screenshots / GIFs

Tests

• In DefaultRoomLastMessageFormatter.kt, replace one of the results with some buildString { ... } that ends up having several thousand characters without any line breaks.
• Run the app with those changes.

If it doesn't crash, the substring is doing its job and the issue is fixed. To be sure you can remove the trailing .take(MAX_SAFE_LENGTH) expression.

Tested devices

• Physical
• Emulator
• OS version(s): 14

Checklist

• Changes have been tested on an Android device or Android emulator with API 23
• UI change has been tested on both light and dark themes
• Accessibility has been taken into account. See https://github.com/element-hq/element-x-android/blob/develop/CONTRIBUTING.md#accessibility
• Pull request is based on the develop branch
• Pull request includes a new file under ./changelog.d. See https://github.com/element-hq/element-x-android/blob/develop/CONTRIBUTING.md#changelog
• Pull request includes screenshots or videos if containing UI changes
• Pull request includes a sign off
• You've made a self review of your PR

[jmartinesp]

I mentioned it in the PR description, but I'll add it here too for more visibility:

This can affect the rendering of the timeline too, but I'm not sure about how to handle this. Should we hard truncate them at N length? Should we look for the first \n char and if it's > N truncate it then, although this could have performance implications? Should we add some suffix to the end of the message to make sure users understand it's been truncated?

[github-actions]

📱 Scan the QR code below to install the build (arm64 only) for this PR.

If you can't scan the QR code you can install the build via this link: https://i.diawi.com/13ztnp

[sonarqubecloud]

Quality Gate passed

Kudos, no new issues were introduced!

0 New issues
0 Security Hotspots
No data about Coverage
No data about Duplication

See analysis details on SonarCloud

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (5cf4dc8) 66.95% compared to head (0f8c49c) 67.03%.
Report is 18 commits behind head on develop.

Additional details and impacted files

@@             Coverage Diff             @@
##           develop    #2163      +/-   ##
===========================================
+ Coverage    66.95%   67.03%   +0.08%     
===========================================
  Files         1375     1375              
  Lines        34236    34188      -48     
  Branches      7546     7449      -97     
===========================================
- Hits         22922    22918       -4     
+ Misses        7675     7653      -22     
+ Partials      3639     3617      -22     

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

[bmarty]

Thanks!

[bmarty]

512 would have been nicer to me 🤓

[jmartinesp]

@bmarty thanks for the approval!

I mentioned it in the PR description, but I'll add it here too for more visibility:

This can affect the rendering of the timeline too, but I'm not sure about how to handle this. Should we hard truncate them at N length? Should we look for the first \n char and if it's > N truncate it then, although this could have performance implications? Should we add some suffix to the end of the message to make sure users understand it's been truncated?

Any ideas on this? Should we discuss it tomorrow and iterate on this PR once we've decided how to handle these messages in the timeline?

[bmarty]

Yes, let's discuss this IRL.

[jmartinesp]

We'll discuss the problem with the timeline with the product team and come up with a different solution for it. We're merging this in the meantime.