[$250] Thread-Infinite Loading Occurs When Replying to a Deleted Parent Message

[IuliiaHerets]

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.21-0
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught on HybridApp, is this reproducible on New Expensify Standalone?: N/A
If this was caught during regression testing, add the test name, ID and link from TestRail: N/A
Email or phone of affected tester (no customers): applausetester+tw4342424242@applause.expensifail.com
Issue reported by: Applause Internal Team
Device used: Mac 13.6/chrome
App Component: Other

Action Performed:

Prerequisite:-You should have two accounts: User A and User B.

1. Sign in with User A.
2. Click FAB > Start Chat > Enter User B's Email.
3. In DM, send a message to User B.
4. Sign in as User B, open the message thread from User A.
5. Switch back to User A, right-click on the message, edit, erase content, and click delete.
6. Go back to User B, write a reply in the thread.
7. Notice the header enters an infinite loading state.

Expected Result:

User B should not be able to reply if the parent message is deleted by User A, and the deleted message should also be removed from User B’s view.

Actual Result:

User B is able to reply to a deleted message, and the header enters an infinite loading state.

Workaround:

Unknown

Platforms:

• Android: Standalone
• Android: HybridApp
• Android: mWeb Chrome
• iOS: Standalone
• iOS: HybridApp
• iOS: mWeb Safari
• MacOS: Chrome / Safari
• MacOS: Desktop

Screenshots/Videos

Bug6787979_1743431804425.ScreenRecording_03-31-2025_22-32-51_1.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~021907138375232609940
• Upwork Job ID: 1907138375232609940
• Last Price Increase: 2025-04-08

Issue Owner

Current Issue Owner: @shubham1206agra

[melvin-bot]

Triggered auto assignment to @OfstadC (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.

[melvin-bot]

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

[melvin-bot]

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

[djordjemitrovic00]

Proposal

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

User A and User B are chatting.
User A sends a message.
User B clicks "Reply to thread" and begins typing a response in a new chat window.
While User B is still typing (and hasn’t clicked Send yet), User A deletes the original message.

At this point, User B should no longer be allowed to send a message. However, the current behavior allows them to continue typing, and the Send button remains active. Additionally:

• The Header shows a loading skeleton instead of displaying "Deleted message."
• In the sidebar, the thread appears empty instead of showing "Deleted message."

What is the root cause of that problem?

In the scenario described above, the message that User B receives via the WebSocket contains the flag isDeletedParentAction = false, but it also includes a deleted property indicating the message has been deleted. As a result, the HeaderView.tsx component does not render a title. Since one of the conditions for determining whether to display a loading skeleton or actual data depends on the presence of a title, the header remains stuck in a loading state.

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

Previously, we only checked whether the isDeletedParentAction flag was set to true to determine if a chat thread was deleted. However, we should introduce a utility function called isChatThreadDeleted in ReportUtils.ts that also checks whether the deleted property is null. If deleted is not null, we can treat the thread as deleted.

With this approach, the HeaderView.tsx component will correctly display the title "Deleted message" instead of showing a loading skeleton. Additionally, in the sidebar, "Hidden" will be displayed instead of an empty string.

(By the way, should those conversations be considered fully deleted too? Might be worth clarifying.)

Additionally, if the expected behavior is to prevent sending messages when a chat thread is deleted, we should export the isChatThreadDeleted function from ReportUtils.ts and use it in ReportFooter.tsx. There, we can determine whether the thread is deleted and pass that information as a flag to the SendButton component to disable message sending accordingly.

If message sending isn't restricted for deleted threads, messages will still be sent, but they won't be persisted anywhere, which could lead to confusion or data loss.

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

We should handle cases where a message arrives with isDeletedParentAction = false but still includes the deleted property, as this indicates the thread is effectively deleted. Additionally, the logic for preventing message sending in such cases should be covered with appropriate tests to ensure consistent behavior.

What alternative solutions did you explore? (Optional)

I haven't explored alternative solutions yet, though one possible workaround could be setting isDeletedParentAction = true before sending the message through the WebSocket. This might also resolve the issue. However, even with that approach, we still need to ensure that sending messages is explicitly forbidden when the thread is deleted.

[melvin-bot]

📣 @djordjemitrovic00! 📣
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>

[djordjemitrovic00]

Contributor details
Your Expensify account email: mitrovicdjordje00@gmail.com
Upwork Profile Link: https://www.upwork.com/freelancers/~0188442d2ac3f1a4fa

[melvin-bot]

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

[shubham1206agra]

Asked for internal help https://expensify.slack.com/archives/C06ML6X0W9L/p1743832284211829