Mobile: Fix #15104: Truncate verbose decryption error payloads in Status screen

[Ehtesham-Zahid]

Fixes #15104

AI Assistance Disclosure
I used AI to navigate the project's codebase and trace the sync status data flow.

Problem
On the mobile Sync Status screen, decryption error payloads (e.g., corrupted cipher text) render as an infinite "wall of text." This breaks the UI layout and makes it difficult to navigate the status report or access the "Retry/Ignore" buttons.

Solution
I simplified the fix by applying numberOfLines={2} directly to the text component. Since status items are usually short, this prevents the layout from breaking without needing extra properties in the data layer.

Test Plan
I verified the fix by simulating long decryption error strings in the sync report. Long messages now truncate to 2 lines with an ellipsis, while standard status items remain unaffected. (See attached video)

Video Demonstration
vid5.webm

[coderabbitai]

📝 Walkthrough

Walkthrough

Updated renderItem in the sync status screen to render item text with numberOfLines={2} and ellipsizeMode='tail', limiting displayed lines and truncating overflow.

Changes

Cohort / File(s)	Summary
Sync Status Screen packages/app-mobile/components/screens/status.tsx	Modified renderItem so the Text element always uses numberOfLines={2} and ellipsizeMode='tail' to truncate long item text.

Suggested reviewers

• mrjo118

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title accurately summarizes the main change: fixing issue #15104 by truncating verbose decryption error payloads in the mobile Status screen.
Linked Issues check	✅ Passed	The code changes directly address issue #15104 by applying numberOfLines={2} and ellipsizeMode='tail' to truncate verbose decryption error payloads in the Status screen, matching the expected behaviour of limiting content display.
Out of Scope Changes check	✅ Passed	The single-line change is narrowly scoped to the Text rendering in renderItem, directly addressing the truncation requirement for decryption errors without altering unrelated functionality.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Description check	✅ Passed	The pull request description clearly relates to the changeset, explaining the problem (long decryption error payloads breaking the mobile UI), the solution (applying numberOfLines={2}), and testing performed.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@packages/app-mobile/components/screens/status.tsx`:
- Around line 208-209: The code currently detects a decryption header using a
hard-coded English string in the isFailedDecryptionErrorHeader check; replace
that literal check with the localized string lookup used elsewhere (e.g. call
the same i18n/_ function or translation helper that produces "Items with error:"
so the check becomes text?.startsWith(_('Items with error:')) or the app's
equivalent), keeping the existing guard on item.sectionName ===
'failedDecryption' and preserving the use of isFailedDecryptionErrorHeader in
the textComponent logic.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: 19c0e2bd-3928-476c-b432-d3b5110d8831

📥 Commits

Reviewing files that changed from the base of the PR and between cbdb3f1 and 1e1167f.

📒 Files selected for processing (1)

• packages/app-mobile/components/screens/status.tsx

[laurent22]

Honestly your PR description looks a bit ridiculous with phrases like "Zero-Impact Design" or "Targeted Truncation". This looks like a Linkedin post from someone who wants to be taken seriously but has no idea what they're talking about. I'm telling you this for your own sake - don't rely too much on LLM for this, that looks unprofessional

[Ehtesham-Zahid]

thanks for the feedback, Laurent! You’re right, pr description is definitely overdone. I used an LLM to polish my raw descritpion and it added way too much fluff. I see how that looks unprofessional, i will stick to my own technical wording from now on. sorry about that!