[$250] LHN - Duplicate chats missing red dot indicator

[vincdargento]

If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!

---

Version Number: 9.3.58-0
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: https://test-management.browserstack.com/projects/2219752/test-runs/TR-17853/folder/13177075/41237838/1321448428?sort=-status_id
Email or phone of affected tester (no customers): casluyo@gmail.com
Issue reported by: Applause Internal Team
Bug source: Regression TC Execution
Device used: samsung s25/ android 16
App Component: Other

Action Performed:

1. Open the Expensify app on the main device.
2. Log in with the same account on both main and secondary devices.
3. Turn off internet on the main device.
4. On the secondary device, create a group with yourself and 2 users, then split expense between the 2 users.
5. On the main device (offline), create the same split expense with the same 2 users.
6. Re‑enable internet on the main device.

Expected Result:

• Duplicate chats should appear in the LHN.
• One of each duplicate pair should show a red dot.

Actual Result:

• Duplicate chats appear in the LHN but no red dot indicator is shown.

Workaround:

Unknown

Platforms:

• Android: App
• Android: mWeb Chrome
• iOS: App
• iOS: mWeb Safari
• iOS: mWeb Chrome
• Windows: Chrome
• MacOS: Chrome / Safari

Screenshots/Videos

bug.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @getusha

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022043671846911456513
• Upwork Job ID: 2043671846911456513
• Last Price Increase: 2026-04-13
• Automatic offers:
• thelullabyy | Reviewer | 111194648

[MelvinBot]

Proposal

What is the root cause of that problem?

When a split expense is created offline and then the device reconnects, duplicate chats appear but neither shows a red dot because lastReadTime is always set equal to or later than lastVisibleActionCreated through multiple reinforcing paths:

1. Optimistic creation sets lastReadTime = now — at IOU/index.ts:3698, the split flow explicitly sets splitChatReport.lastReadTime = DateUtils.getDBTime(), which equals or exceeds the action's created timestamp, so isUnread() returns false.

2. replaceOptimisticReportWithActualReport overwrites local state — at replaceOptimisticReportWithActualReport.ts:100-106, when a preexisting report is detected, Onyx.set completely replaces the report with server data. The server considers the creating user to have "seen" the report, so lastReadTime >= lastVisibleActionCreated in the server response — no unread state survives.

3. Auto-navigation marks it read — after creating a split, dismissModalAndOpenReportInInboxTab navigates to the report, which fires readNewestAction (Report/index.ts:2312), advancing lastReadTime even further.

The core unread check is at ReportUtils.ts:9040-9058: lastReadTime < lastVisibleActionCreated. Because all three paths above ensure lastReadTime >= lastVisibleActionCreated, the red dot never appears.

Additionally, SidebarUtils.ts:804 guards the unread indicator with !!report.lastActorAccountID, which can be 0 on optimistic reports, further suppressing the dot.

What changes do you think we should make in order to solve the problem?

In replaceOptimisticReportWithActualReport, when merging the server report onto the preexisting report, preserve the earlier of the existing lastReadTime and the server's lastReadTime rather than unconditionally overwriting. This ensures that if the preexisting report had actions the user hasn't seen (created by the other device or other participants while offline), those actions remain unread.

Specifically, at replaceOptimisticReportWithActualReport.ts:100-106, the Onyx.set call should compare existingReport?.lastReadTime with report.lastReadTime and keep the earlier value:

lastReadTime: existingReport?.lastReadTime && existingReport.lastReadTime < (report.lastReadTime ?? '')
    ? existingReport.lastReadTime
    : report.lastReadTime,

This is the minimal change — it only affects the duplicate-report reconciliation path and preserves the unread state for actions the user genuinely hasn't viewed.

What alternative solutions did you explore? (Optional)

• Modifying the server to send lastReadTime = null for duplicate reports: This would work but requires a backend change and could have broader side effects on other clients.
• Suppressing readNewestAction during the split-creation navigation: This would help one path but wouldn't fix the replaceOptimisticReportWithActualReport overwrite, which is the more fundamental issue.

---

Next Steps for Contributor+ team: Reply with @MelvinBot implement this to create a draft PR, @MelvinBot <your feedback> to refine this analysis, or explain why you are rejecting Melvin's proposal.

[melvin-bot]

Triggered auto assignment to Contributor-plus team member for initial proposal review - @thelullabyy (External)

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~022043671846911456513

[MobileMage]

Proposal

Please re-state the problem that we are trying to solve in this issue.

When a user creates a split expense offline and the same split is created on another device simultaneously, both chats appear in the LHN as duplicates after reconnecting, but neither shows a red dot indicator for the unread message from the other device's chat.

What is the root cause of that problem?

The unread state for a report in the LHN is computed in SidebarUtils.ts as:

result.isUnread = isUnread(report, oneTransactionThreadReport, isReportArchived) && !!report.lastActorAccountID;

App/src/libs/SidebarUtils.ts

Line 804 in a367f8b

result.isUnread = isUnread(report, oneTransactionThreadReport, isReportArchived) && !!report.lastActorAccountID;

The !!report.lastActorAccountID guard was introduced to prevent empty chats (where the only message was deleted) from showing as unread since lastVisibleActionCreated is not reset after deletion. However, buildOptimisticChatReport in ReportUtils.ts initializes lastActorAccountID: 0 for all new optimistic reports. When the duplicate report (created by the other device) arrives after reconnection, the Onyx merge may retain lastActorAccountID: 0 if the server's payload hasn't yet updated that field — 0 is falsy, so !!report.lastActorAccountID evaluates to false and the red dot is suppressed despite isUnread() returning true.

App/src/libs/ReportUtils.ts

Line 7917 in a367f8b

lastActorAccountID: 0,

What changes do you think we should make in order to solve the problem?

The !!report.lastActorAccountID guard should only suppress the unread indicator for the specific case it was meant to handle: an empty report where all messages were deleted. The right condition to detect that case is isEmptyReport, which is already called inside isUnread itself. We can drop the lastActorAccountID guard and instead rely on the existing isEmptyReport check inside isUnread — or, to be minimally invasive, also allow isUnread to pass when lastMessageText is present (meaning the chat is not actually empty), regardless of whether lastActorAccountID is populated.

The cleanest fix is to replace the blunt !!report.lastActorAccountID guard with a check that only suppresses when the report has no visible last message text, which is the actual observable state of an "all messages deleted" empty report:

-    result.isUnread = isUnread(report, oneTransactionThreadReport, isReportArchived) && !!report.lastActorAccountID;
+    // When the only message of a report is deleted, lastVisibleActionCreated is not reset, which would
+    // wrongly mark the chat as unread. Guard against this by checking lastMessageText instead of
+    // lastActorAccountID, which can be 0 on valid unread reports (e.g. duplicate chats after offline sync).
+    result.isUnread = isUnread(report, oneTransactionThreadReport, isReportArchived) && (!!report.lastActorAccountID || !!report.lastMessageText);

This preserves the original intent — a report with no actor AND no message text is genuinely empty — while allowing duplicate chats that have a lastMessageText but a zeroed lastActorAccountID to correctly display the red dot.

What alternative solutions did you explore? (Optional)

An alternative would be to ensure buildOptimisticChatReport never sets lastActorAccountID: 0, but this field is intentionally unset for new chats before any action is taken and is populated by the server. Changing the source of truth there could cause other side effects. Adjusting the LHN display condition is more targeted and does not require changing the data model.

[trasnake87]

Proposal

Please re-state the problem that we are trying to solve in this issue.

When a user creates a split expense while offline, reconnects, and the server detects that a matching chat already exists, duplicate chat entries show up in the LHN but none of them display the unread red dot indicator the user expects.

What is the root cause of that problem?

The HandleUnusedOptimisticID middleware at src/libs/Middleware/HandleUnusedOptimisticID.ts handles the preexistingReportID remapping — it rewrites persisted requests so the queued offline actions post against the real (preexisting) report. However, it never touches the preexisting report's lastReadTime. When OpenReport's response comes back, the server's lastReadTime for the preexisting report was computed before the remapped offline actions posted to it, but because the local client treats the remapped report as "just opened" (the optimistic flow effectively authored the session), the preexisting report's lastReadTime is left greater-than-or-equal to its eventual lastVisibleActionCreated. The middleware knows exactly when a duplicate was detected (preexistingReportID branch around line 51-61) but fails to mark the surviving report as unread at that moment.

What changes do you think we should make in order to solve the problem?

In the preexistingReportID branch of HandleUnusedOptimisticID, push an Onyx MERGE that resets lastReadTime on the preexisting report so the remapped actions render as unread:

if (preexistingReportID) {
    (response.onyxData as AnyOnyxUpdate[]).push({
        onyxMethod: Onyx.METHOD.MERGE,
        key: `${ONYXKEYS.COLLECTION.REPORT}${preexistingReportID}`,
        value: {
            lastReadTime: DateUtils.subtractMillisecondsFromDateTime(DateUtils.getDBTime(), 1000),
        },
    });
}

This guarantees lastReadTime < lastVisibleActionCreated for the preexisting report at the precise moment duplication is detected, so isUnread() returns true and the LHN brick-road red dot renders — without touching the optimistic split creation path or the generic report-read navigation flow.

[trasnake87]

Contributor details
Your Expensify account email: trasnake87@gmail.com
Upwork Profile Link: https://www.upwork.com/freelancers/~010f770315ab181656

[melvin-bot]

✅ Contributor details stored successfully. Thank you for contributing to Expensify!

[melvin-bot]

📣 @skylarkerx! 📣
Hey, it seems we don’t have your contributor details yet! You'll only have to do this once, and this is how we'll hire you on Upwork.
Please follow these steps:

1. Make sure you've read and understood the contributing guidelines.
2. Get the email address used to login to your Expensify account. If you don't already have an Expensify account, create one here. If you have multiple accounts (e.g. one for testing), please use your main account email.
3. Get the link to your Upwork profile. It's necessary because we only pay via Upwork. You can access it by logging in, and then clicking on your name. It'll look like this. If you don't already have an account, sign up for one here.
4. Copy the format below and paste it in a comment on this issue. Replace the placeholder text with your actual details.
   
   Format:

Contributor details
Your Expensify account email: <REPLACE EMAIL HERE>
Upwork Profile Link: <REPLACE LINK HERE>