[Due for payment 2026-04-14] [$250] Thread - Leave thread works only when use it second time

[jponikarchuk]

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: v9.3.43-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: #85437
Email or phone of affected tester (no customers): gocemate+b215490617@gmail.com
Issue reported by: Applause Internal Team
Bug source: Pull Request QA execution
Device used: Windows 10/Chrome
App Component: Other

Action Performed:

1. Go to any chat
2. Send a message and add reply
3. Go to the parent message on mail chat> In the context menu select "Leave thread"
4. Open the context menu again

Expected Result:

Join thread option should appear

Actual Result:

"Leave thread" appears even user already left the thread. "Join thread" option appears only when leave thread again

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Video.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @mallenexpensify

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022036744553496622356
• Upwork Job ID: 2036744553496622356
• Last Price Increase: 2026-03-25

[MelvinBot]

Proposal

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

After clicking "Leave thread" in a thread's context menu, the option still shows "Leave thread" instead of switching to "Join thread". The toggle only works correctly on the second attempt.

What is the root cause of that problem?

The root cause is a race condition in toggleSubscribeToChildReport (src/libs/actions/Report/index.ts:2995-3053). When the user clicks "Leave thread", this function calls openReport() before updateNotificationPreference():

Line 3006: openReport({reportID: childReportID, ...});   // called FIRST
Line 3018: updateNotificationPreference(childReportID, prevPref, 'hidden', ...);  // called SECOND

Both are API.write() calls that apply optimistic data immediately. The optimistic update from updateNotificationPreference correctly sets childReportNotificationPreference to 'hidden' on the parent report action in Onyx. However, both requests enter the sequential write queue. The OpenReport request is sent to the server first, and its response can include the parent report action with the old childReportNotificationPreference value (since UpdateNotificationPreference hasn't been processed by the server yet). When the OpenReport server response arrives and merges into Onyx, it overwrites the optimistic 'hidden' value with the stale server value.

On the second click, the server has already processed the first UpdateNotificationPreference, so the OpenReport response now returns the correct 'hidden' value, and the toggle appears to work.

The shouldShow logic for "Leave thread" (ContextMenuActions.tsx:671-688) checks getChildReportNotificationPreference(reportAction) !== 'hidden', and the context menu reads this value reactively from Onyx via useOnyx in BaseReportActionContextMenu.tsx:170-180.

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

In toggleSubscribeToChildReport (src/libs/actions/Report/index.ts:3005-3006), move the openReport() call after the updateNotificationPreference() call. This ensures the UpdateNotificationPreference request is queued first in the sequential write queue and processed by the server before OpenReport. That way, the OpenReport server response will include the already-updated childReportNotificationPreference value and won't overwrite the optimistic data.

The same reordering should be applied in the else branch (line 3041-3051) for consistency, though that branch handles creating new threads so it's less likely to hit this issue.

What alternative solutions did you explore? (Optional)

1. Skip the openReport call when the child report already exists: Since openReport is mainly needed to load report data, and for an existing thread the data should already be available, we could conditionally skip it. However, this might break edge cases where the thread data hasn't been loaded yet.

2. Add successData to updateNotificationPreference: Currently updateNotificationPreference only has optimisticData and failureData but no successData for childReportNotificationPreference. Adding successData that re-asserts the correct value could help, but it wouldn't fully prevent the race since OpenReport response arrives before UpdateNotificationPreference succeeds.

---

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 - @truph01 (External)

[melvin-bot]

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

[twilight2294]

Proposal

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

When clicking "Leave thread" in a thread's context menu, the action doesn't take effect on the first attempt — the option still shows "Leave thread" instead of switching to "Join thread." It only works correctly on the second click.

What is the root cause of that problem?

The root cause is a race condition in toggleSubscribeToChildReport() in Report. When the user clicks "Leave thread," openReport() is called unconditionally on line 3056 — regardless of whether we're joining or leaving. Then updateNotificationPreference() is called afterward to set the preference to 'hidden'.

Both calls go through the sequential write queue. openReport() is queued first, so it hits the server before updateNotificationPreference(). When the server responds to OpenReport, it returns the parent report action with the stale childReportNotificationPreference value ('always'), because the UpdateReportNotificationPreference command hasn't been processed yet. This server response overwrites the optimistic 'hidden' value that updateNotificationPreference() had applied locally.

The shouldShow logic for "Leave thread" in ContextMenuActions checks getChildReportNotificationPreference() from ReportUtils, and since the stale value was merged back, the UI still shows "Leave thread." On the second click, the server has already processed the first preference update, so OpenReport returns the correct value and everything works.

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

Move the openReport() call inside the join branch only. When leaving a thread, there's no reason to open it — the user is leaving, not navigating into it. This eliminates the race condition entirely because openReport's server response can no longer overwrite the optimistic preference update.

In Report:

if (childReportID) {
    const parentReportActionID = parentReportAction.reportActionID;
    if (!prevNotificationPreference || isHiddenForCurrentUser(prevNotificationPreference)) {
        // Joining: open the report then subscribe
        openReport({reportID: childReportID, introSelected, betas, isSelfTourViewed});
        updateNotificationPreference(
            childReportID, prevNotificationPreference,
            CONST.REPORT.NOTIFICATION_PREFERENCE.ALWAYS,
            currentUserAccountID, parentReport?.reportID, parentReportActionID,
        );
    } else {
        // Leaving: only update the preference, skip openReport to avoid
        // its server response overwriting the optimistic 'hidden' value
        updateNotificationPreference(
            childReportID, prevNotificationPreference,
            CONST.REPORT.NOTIFICATION_PREFERENCE.HIDDEN,
            currentUserAccountID, parentReport?.reportID, parentReportActionID,
        );
    }
}

What alternative solutions did you explore? (Optional)

MelvinBot's existing proposal identifies the same race condition but suggests simply reordering the calls (putting updateNotificationPreference before openReport). While that helps with server-side ordering in the sequential queue, it doesn't fully prevent the issue — openReport's server response can still arrive and merge stale data into Onyx after the optimistic update, since both requests are in-flight and Onyx merges server responses as they arrive. The cleaner fix is to not call openReport at all when leaving, since it serves no purpose in that code path and is the sole source of the stale data overwrite.

[trasnake87]

🚫 Duplicated proposal withdrawn by 🤖 ProposalPolice.

[github-actions]

⚠️ @trasnake87 Your proposal is a duplicate of an already existing proposal and has been automatically withdrawn to prevent spam. Please review the existing proposals before submitting a new one.

[MobileMage]

🚫 Duplicated proposal withdrawn by 🤖 ProposalPolice.