[HOLD for payment 2024-04-05] [$500] Chat - "Auth OpenReport returned an error" appears when refresh thread page from archived chat

[lanitochka17]

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: 1.4.45-0
Reproducible in staging?: Y
Reproducible in production?: Y
If this was caught during regression testing, add the test name, ID and link from TestRail: https://expensify.testrail.io/index.php?/tests/view/4350580
Email or phone of affected tester (no customers): applausetester+0507gm@applause.expensifail.com
Logs: https://stackoverflow.com/c/expensify/questions/4856
Expensify/Expensify Issue URL:
Issue reported by: Applause - Internal Team
Slack conversation:

Action Performed:

Precondition:

1. As Admin create Workspace
2. Invite a member to Workspace
3. Send a message to the individual workspace chat
4. Delete the Workspace
5. Navigate to archived individual chat
6. Hover over send message and click Reply in thread
7. Refresh the page

Expected Result:

There should be no error message when refresh page

Actual Result:

"Auth OpenReport returned an error" system message appear when refresh thread page from archived individual workspace chat

Workaround:

Unknown

Platforms:

Which of our officially supported platforms is this issue occurring on?

• Android: Native
• Android: mWeb Chrome
• iOS: Native
• iOS: mWeb Safari
• MacOS: Chrome / Safari
• MacOS: Desktop

Screenshots/Videos

Add any screenshot/video evidence

Bug6397412_1709230358381.Recording__2411.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~01b01e8b28bedc178c
• Upwork Job ID: 1763637794748841984
• Last Price Increase: 2024-03-08

Issue Owner

Current Issue Owner: @akinwale

[melvin-bot]

Triggered auto assignment to @garrettmknight (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details.

[lanitochka17]

@garrettmknight FYI I haven't added the External label as I wasn't 100% sure about this issue. Please take a look and add the label if you agree it's a bug and can be handled by external contributors

[gijoe0295]

Proposal

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

Chat - "Auth OpenReport returned an error" appears when refresh thread page from archived chat

What is the root cause of that problem?

We currently allow user to reply to a message in an archived chat.

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

We should not allow user to reply to a message in an archived chat by modify shouldDisableThread here to include another condition: isArchivedRoom && !reportAction?.childVisibleActionCount.

By doing this, we can make sure that if the report action has child replies, we should show the reply in thread button because user still has access to the thread. It's what we've done with deleted action here.

What alternative solutions did you explore? (Optional)

NA

[garrettmknight]

Agreed that this shouldn't be allowed.

[melvin-bot]

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

[melvin-bot]

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

[garrettmknight]

@akinwale we already have a proposal above, heads up!

[rayane-d]

Dupe of #37603
it has the same RCA

[rayane-d]

Bringing my proposal from #37603 (comment) in case we want to keep this issue instead:

Proposal

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

"Reply Thread" Button Available in Archived Workspaces Despite User Inability to Reply.

What is the root cause of that problem?

Here:

App/src/pages/home/report/ContextMenu/ContextMenuActions.tsx

Lines 184 to 189 in e13819e

	shouldShow: (type, reportAction, isArchivedRoom, betas, menuTarget, isChronosReport, reportID) => {
	if (type !== CONST.CONTEXT_MENU_TYPES.REPORT_ACTION) {
	return false;
	}
	return !ReportUtils.shouldDisableThread(reportAction, reportID);
	},

we don't have a condition to disable the "reply in thread" action when the report is archived.

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

we should return false in shouldShow here if the report is archived:

if (isArchivedRoom){
    return false;
}

Result

Archived.report.disable.reply.Recording.2024-03-01.170539.mp4

What alternative solutions did you explore? (Optional)

We can include a check to enable the "Reply in Thread" action buttons for report actions with reportAction?.childVisibleActionCount, but I believe it's more logical to disable the "Reply in Thread" option for actions with existing replies, as users cannot add further replies, and the option's name might be confusing in this context. We should deactivate the option. If users wish to view existing replies, they can click on the replies count link to open the thread.

[gijoe0295]

Updated proposal to include detailed explanation (no changes in solution).

[dukenv0307]

Proposal

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

The "Reply Thread" button is available in archived workspaces, even though users cannot reply to the thread.

What is the root cause of that problem?

We don't disable reply in thread for report action of archived room

App/src/libs/ReportUtils.ts

Line 4965 in 623c191

function shouldDisableThread(reportAction: OnyxEntry<ReportAction>, reportID: string): boolean {

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

1. We should add an extra param like isArchivedRoom for shouldDisableThread and add another case that we should disable thread if the room is archived and this action isn't replied in thread before isArchivedRoom && !reportAction.childReportID

We shouldn't use childVisibleActionCount to check for this case because if we have already replied in thread before we archived the room we should enable reply in thread for this action

App/src/libs/ReportUtils.ts

Line 4965 in 623c191

function shouldDisableThread(reportAction: OnyxEntry<ReportAction>, reportID: string): boolean {

2. And then pass isArchivedRoom here into shouldDisableThread function

return !ReportUtils.shouldDisableThread(reportAction, reportID, isArchivedRoom);

App/src/pages/home/report/ContextMenu/ContextMenuActions.tsx

Line 183 in 6db1843

return !ReportUtils.shouldDisableThread(reportAction, reportID);

What alternative solutions did you explore? (Optional)

NA

[melvin-bot]

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

[garrettmknight]

@akinwale can you review these proposals?

[akinwale]

I will review later today.

[akinwale]

@garrettmknight I have not been able to reproduce the error following the specified steps.

[dukenv0307]

@akinwale Still able to reproduce on staging.

Screen.Recording.2024-03-08.at.10.09.54.mov

[akinwale]

@akinwale Still able to reproduce on staging.

Ok, I was able to reproduce after deleting the workspace to arrive at this state. Reviewing the proposals now.

[akinwale]

After reviewing, we can move forward to @gijoe0295's proposal since the solution follows the same idea as a previous implementation (delete thread).

🎀👀🎀 C+ reviewed.

[melvin-bot]

Triggered auto assignment to @roryabraham, see https://stackoverflow.com/c/expensify/questions/7972 for more details.

[roryabraham]

@gijoe0295 your proposal looks good, but I'm going to require that we add unit tests to cover this function. Thanks!

[melvin-bot]

❌ There was an error making the offer to @akinwale for the Reviewer role. The BZ member will need to manually hire the contributor.

[melvin-bot]

❌ There was an error making the offer to @gijoe0295 for the Contributor role. The BZ member will need to manually hire the contributor.

[roryabraham]

@garrettmknight looks like the Upwork automation needs some help ☝🏼

[garrettmknight]

@gijoe0295 @akinwale new offers out.

[akinwale]

@gijoe0295 @akinwale new offers out.

Accepted. Thanks!

[melvin-bot]

Reviewing label has been removed, please complete the "BugZero Checklist".

[melvin-bot]

The solution for this issue has been 🚀 deployed to production 🚀 in version 1.4.57-5 and is now subject to a 7-day regression period 📆. Here is the list of pull requests that resolve this issue:

• Disable thread in archived room #38251

If no regressions arise, payment will be issued on 2024-04-05. 🎊

For reference, here are some details about the assignees on this issue:

• @akinwale requires payment (Needs manual offer from BZ)
• @gijoe0295 requires payment (Needs manual offer from BZ)

[melvin-bot]

BugZero Checklist: The PR fixing this issue has been merged! The following checklist (instructions) will need to be completed before the issue can be closed:

• [@akinwale] The PR that introduced the bug has been identified. Link to the PR:
• [@akinwale] The offending PR has been commented on, pointing out the bug it caused and why, so the author and reviewers can learn from the mistake. Link to comment:
• [@akinwale] A discussion in #expensify-bugs has been started about whether any other steps should be taken (e.g. updating the PR review checklist) in order to catch this type of bug sooner. Link to discussion:
• [@akinwale] Determine if we should create a regression test for this bug.
• [@akinwale] If we decide to create a regression test for the bug, please propose the regression test steps to ensure the same bug will not reach production again.
• [@garrettmknight] Link the GH issue for creating/updating the regression test once above steps have been agreed upon:

[melvin-bot]

Payment Summary

Upwork Job

• ROLE: @akinwale paid $500 via Upwork
• ROLE: @gijoe0295 paid $500 via Upwork

BugZero Checklist (@garrettmknight)

• I have verified the correct assignees and roles are listed above and updated the neccesary manual offers
• I have verified that there are no duplicate or incorrect contracts on Upwork for this job (https://www.upwork.com/ab/applicants/1763637794748841984/hired)
• I have paid out the Upwork contracts or cancelled the ones that are incorrect
• I have verified the payment summary above is correct

[garrettmknight]

@akinwale can you complete the checklist?

[akinwale]

BugZero Checklist: The PR fixing this issue has been merged! The following checklist (instructions) will need to be completed before the issue can be closed:

• [@akinwale] The PR that introduced the bug has been identified. Link to the PR:
• [@akinwale] The offending PR has been commented on, pointing out the bug it caused and why, so the author and reviewers can learn from the mistake. Link to comment:
• [@akinwale] A discussion in #expensify-bugs has been started about whether any other steps should be taken (e.g. updating the PR review checklist) in order to catch this type of bug sooner. Link to discussion:

Not a regression. This specific case was not handled.

• [@akinwale] Determine if we should create a regression test for this bug.
• [@akinwale] If we decide to create a regression test for the bug, please propose the regression test steps to ensure the same bug will not reach production again.

Regression Test Steps

1. Launch Expensify.
2. Create a new workspace.
3. Send a message in the #announce room.
4. Send another message in the #announce room.
5. Create a thread from the message sent in 3 and send a reply in the thread.
6. Delete the workspace.
7. Navigate to the archived #announce room.
8. Move the mouse over the parent message sent in step 3.
9. Verify that the Reply in thread option is visible.
10. Click Reply in thread.
11. Verify that navigation occurs to the thread.
12. Move the mouse the other message in the archived #announce room.
13. Verify that the Reply in thread option is not visible.

Do we agree 👍 or 👎?

[akinwale]

@garrettmknight Done.

[garrettmknight]

Thanks!