[Due for payment 2025-11-03] [$250] Chat - Delete multilevel thread does not update reply count correctly

[nlemma]

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.1.83-4
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from TestRail: 2649481 - https://docs.google.com/spreadsheets/d/1xgmP-nEeoR-F_gnhxvQucXjETKq0u7hq9oKJ5BqXMr8/edit?gid=1991600751#gid=1991600751
Email or phone of affected tester (no customers): ndk.2303+123@gmail.com
Issue reported by: Applause Internal Team
Device used: Windows 11 Home/Chrome
App Component: Chat Report View

Action Performed:

Preconditions: Create a multilevel thread message with at least 2 level in a conversation

1. Open https://staging.new.expensify.com/
2. Naviagte the threaded message level 1
3. Delete the threaded message level 1
4. Click on the 'Reply count'
5. Delete threaded message level 2
6. Navigate to parent conversation

Expected Result:

Delete the multi-level threads message, the reply countshould update accordingly.

Actual Result:

Delete the multi-level threads message, the reply count does not update accordingly. When there is not any reply left the 'reply count' still shows 1 left.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug6893878_1753084484702.Delete_multithread_messages_the_reply_counted_not_updated.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~021950312329677101942
• Upwork Job ID: 1950312329677101942
• Last Price Increase: 2025-08-05

Issue Owner

Current Issue Owner: @muttmuure

[melvin-bot]

Triggered auto assignment to @muttmuure (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details. Please add this bug to a GH project, as outlined in the SO.

[bernhardoj]

Proposal

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

Deleting multilevel thread doesn't update the reply count correctly.

What is the root cause of that problem?

This is both BE and FE optimistic issue. For the optimistic issue, when we delete a thread comment, we subtract all the thread ancestor actions childVisibleActionCount by 1.

App/src/libs/ReportUtils.ts

Lines 5685 to 5688 in 995664d

	} else if (type === CONST.RED_BRICK_ROAD_PENDING_ACTION.DELETE) {
	if (childVisibleActionCount > 0) {
	childVisibleActionCount -= 1;
	}

It doesn't account for the case where multiple actions are removed. For example, in our case, we have
msg A (2 replies)
|- msg B (1 reply) [deleted]
|-- msg C

when we delete C, B is also removed (because it contains no child msg anymore), so the childVisibleActionCount of A should be subtracted by 2 instead of 1.

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

First, we need to update updateOptimisticParentReportAction to accept a new parameter that tells how many childVisibleActionCount to subtract (deleteBy) with a default value of 1, then use it instead of the fixed value.

if (childVisibleActionCount > 0) {
    childVisibleActionCount -= deleteBy;
}

Then, in getOptimisticDataForParentReportAction, have a variable called previousActionDeleted. This tells whether the previous (child) ancestor is deleted or not. Using the example above, in msg A, previousActionDeleted contains the value of whether msg B is deleted or not. If it's deleted, then we will need to subtract it by 2.

App/src/libs/ReportUtils.ts

Lines 9562 to 9568 in 995664d

	return {
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.REPORT_ACTIONS}${ancestorReport.reportID}`,
	value: {
	[ancestorReportAction.reportActionID]: updateOptimisticParentReportAction(ancestorReportAction, lastVisibleActionCreated, type),
	},
	};

const updatedReportAction = updateOptimisticParentReportAction(ancestorReportAction, lastVisibleActionCreated, type, previousActionDeleted ? index + 1: undefined);

previousActionDeleted = isDeletedAction(ancestorReportAction) && updatedReportAction.childVisibleActionCount === 0;

return {
    onyxMethod: Onyx.METHOD.MERGE,
    key: `${ONYXKEYS.COLLECTION.REPORT_ACTIONS}${ancestorReport.reportID}`,
    value: {
        [ancestorReportAction.reportActionID]: updatedReportAction,
    },
};

What specific scenarios should we cover in automated tests to prevent reintroducing this issue in the future?

We can test the exact same case as this issue by having multilevel thread and then delete the last child and verify the childVisibleActionCount is updated correctly.

[melvin-bot]

@muttmuure Uh oh! This issue is overdue by 2 days. Don't forget to update your issues!

[melvin-bot]

@muttmuure 6 days overdue. This is scarier than being forced to listen to Vogon poetry!

[melvin-bot]

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

[melvin-bot]

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