[HOLD for payment 2024-12-16] [$250] Tasks - App goes back to main chat or LHN when editing a task's description

[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: 9.0.22-5
Reproducible in staging?: Y
Reproducible in production?: N
If this was caught during regression testing, add the test name, ID and link from TestRail: https://expensify.testrail.io/index.php?/tests/view/4872853
Email or phone of affected tester (no customers): gatantm+82@gmail.com
Issue reported by: Applause - Internal Team

Action Performed:

1. Go to any chat and create a task
2. Open the task and click on description
3. Make any edits > Save

Expected Result:

The task is saved and user stays on task view

Actual Result:

The user is returned back to the LHN on mobile or the chat that the task was in. The same happens on the name field after the description was edited once

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

Bug6576464_1724099959731.Recording__994.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~0135f56d92cfd4346d
• Upwork Job ID: 1826020469224260035
• Last Price Increase: 2024-10-15
• Automatic offers:
• tsa321 | Contributor | 104546362

Issue Owner

Current Issue Owner: @getusha

[melvin-bot]

Triggered auto assignment to @deetergp (DeployBlockerCash), see https://stackoverflowteams.com/c/expensify/questions/9980/ for more details.

[github-actions]

👋 Friendly reminder that deploy blockers are time-sensitive ⏱ issues! Check out the open `StagingDeployCash` deploy checklist to see the list of PRs included in this release, then work quickly to do one of the following:

1. Identify the pull request that introduced this issue and revert it.
2. Find someone who can quickly fix the issue.
3. Fix the issue yourself.

[lanitochka17]

We think that this bug might be related to #vip-vsp

[daledah]

Edited by proposal-police: This proposal was edited at {your_timestamp_here}.

Proposal

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

The user is returned back to the LHN on mobile or the chat that the task was in. The same happens on the name field after the description was edited once

What is the root cause of that problem?

• When clicking on CTA button in edit description page, we call:
  

  App/src/pages/tasks/TaskDescriptionPage.tsx

  Line 55 in 78c20f0

  Task.editTask(report, {description: values.description});

then:

App/src/pages/tasks/TaskDescriptionPage.tsx

Line 58 in 78c20f0

Navigation.dismissModal(report?.reportID);

then In PR, we call:

App/src/pages/home/report/ReportActionsList.tsx

Line 370 in 78c20f0

Navigation.navigate(ROUTES.REPORT_WITH_ID.getRoute(report.reportID));

• In above, function Navigation.navigate(ROUTES.REPORT_WITH_ID.getRoute(report.reportID)) can be called before Navigation.dismissModal(report?.reportID) hence the app go back to main chat.

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

We can dismiss modal before call editTask in:

App/src/pages/tasks/TaskDescriptionPage.tsx

Line 55 in 78c20f0

Task.editTask(report, {description: values.description});

The same should be applied in edit title flow.

What alternative solutions did you explore? (Optional)

In case Task.editTask will be called, we can move logic:

Navigation.dismissModal(report?.reportID);

to below:

App/src/libs/actions/Task.ts

Line 567 in 6334d36

API.write(WRITE_COMMANDS.EDIT_TASK, parameters, {optimisticData, successData, failureData});

[daledah]

Proposal updated

[bernhardoj]

Proposal

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

The main chat opens after editing task description.

What is the root cause of that problem?

When we edit the task, we notify the report that a new action has been added.

App/src/libs/actions/Task.ts

Lines 568 to 569 in 80236f5

	Report.notifyNewAction(report.reportID, currentUserAccountID);
	}

It will trigger scrollToBottomForCurrentUserAction and if hasNewestReportActionRef is false, then we navigate to the self-report to clear the reportActionID params.

App/src/pages/home/report/ReportActionsList.tsx

Lines 362 to 372 in 80236f5

	const scrollToBottomForCurrentUserAction = useCallback(
	(isFromCurrentUser: boolean) => {
	// If a new comment is added and it's from the current user scroll to the bottom otherwise leave the user positioned where
	// they are now in the list.
	if (!isFromCurrentUser) {
	return;
	}
	if (!hasNewestReportActionRef.current) {
	Navigation.navigate(ROUTES.REPORT_WITH_ID.getRoute(report.reportID));
	return;
	}

After editing the task, we call dismissModal to close the RHP.

App/src/pages/tasks/TaskDescriptionPage.tsx

Lines 55 to 58 in 80236f5

	Task.editTask(report, {description: values.description});
	}
	Navigation.dismissModal(report?.reportID);

In dismissModal, if the target report ID is the same as the topmost report ID, which is true in our case, we simply pop the current screen.

App/src/libs/Navigation/dismissModalWithReport.ts

Lines 70 to 72 in 80236f5

	} else {
	navigationRef.dispatch({...StackActions.pop(), target: state.key});
	}

So, the first navigate to the self-report already closes the RHP and the dismissModal calls pop which brings us back to the parent report.

Even though this happens after my PR where I add the navigate to self-report logic, but we already guard it with hasNewestReportActionRef condition. So, the real issue here is, why is hasNewestReportActionRef false?

The issue is both FE and BE. hasNewestReportAction compares the last report action created with the report lastVisibleActionCreated.

App/src/pages/home/report/ReportActionsList.tsx

Line 295 in 80236f5

const hasNewestReportAction = sortedVisibleReportActions[0]?.created === report.lastVisibleActionCreated;

In FE, we optimistically add the update task description system message, but we don't update the lastVisibleActionCreated.

App/src/libs/actions/Task.ts

Lines 505 to 524 in 80236f5

	const optimisticData: OnyxUpdate[] = [
	{
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.REPORT_ACTIONS}${report.reportID}`,
	value: {[editTaskReportAction.reportActionID]: editTaskReportAction as OnyxTypes.ReportAction},
	},
	{
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.REPORT}${report.reportID}`,
	value: {
	reportName,
	description: reportDescription,
	pendingFields: {
	...(title && {reportName: CONST.RED_BRICK_ROAD_PENDING_ACTION.UPDATE}),
	...(description && {description: CONST.RED_BRICK_ROAD_PENDING_ACTION.UPDATE}),
	},
	errorFields: null,
	},
	},
	];

For the BE issue, looks like the BE doesn't consider the update task system message created as the report lastVisibleActionCreated.

From the screenshot above, we can see that after the EditTask is completed, there are 2 reports onyx data. The first one contains the correct lastVisibleActionCreated but the second one contains the wrong lastVisbibleActionCreated (it contains the report CREATED action created value).

This makes hasNewestReportActionRef always false even if we fix it optimistically because when scrollToBottomForCurrentUserAction is called, the optimistic data is not merged yet, so hasNewestReportActionRef is still false because the report lastVisibleActionCreated from the BE is wrong.

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

The fix must be done for both BE and FE. The BE needs to return the correct lastVisibleActionCreated. In FE, we can optimistically update the report lastVisibleActionCreated in editTask to be the same as the edit task system message created. buildOptimisticEditedTaskFieldReportAction will accept a created param to be used as the created value.

const created = DateUtils.getDBTime();
const editTaskReportAction = ReportUtils.buildOptimisticEditedTaskFieldReportAction({title, description}, created);
const optimisticData: OnyxUpdate[] = [
    {
        onyxMethod: Onyx.METHOD.MERGE,
        key: `${ONYXKEYS.COLLECTION.REPORT}${report.reportID}`,
        value: {
            ...,
            lastVisibleActionCreated: created,
        },
    },
];

[tsa321]

Edited by proposal-police: This proposal was edited at 2023-10-01T00:00:00Z.

Proposal

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

Tasks - App goes back to main chat or LHN when editing a task's description

What is the root cause of that problem?

When user edit task, dismissModal will be executed:

App/src/pages/tasks/TaskDescriptionPage.tsx

Lines 50 to 58 in 6334d36

	const submit = useCallback(
	(values: FormOnyxValues<typeof ONYXKEYS.FORMS.EDIT_TASK_FORM>) => {
	if (values.description !== Parser.htmlToMarkdown(report?.description ?? '') && !isEmptyObject(report)) {
	// Set the description of the report in the store and then call EditTask API
	// to update the description of the report on the server
	Task.editTask(report, {description: values.description});
	}
	Navigation.dismissModal(report?.reportID);

and when before calling API write of edit_task:

App/src/libs/actions/Task.ts

Lines 567 to 568 in 6334d36

	API.write(WRITE_COMMANDS.EDIT_TASK, parameters, {optimisticData, successData, failureData});
	Report.notifyNewAction(report.reportID, currentUserAccountID);

Report.notifyNewAction will be executed first and will execute it's subcribtion function :

App/src/pages/home/report/ReportActionsList.tsx

Lines 362 to 372 in 6334d36

	const scrollToBottomForCurrentUserAction = useCallback(
	(isFromCurrentUser: boolean) => {
	// If a new comment is added and it's from the current user scroll to the bottom otherwise leave the user positioned where
	// they are now in the list.
	if (!isFromCurrentUser) {
	return;
	}
	if (!hasNewestReportActionRef.current) {
	Navigation.navigate(ROUTES.REPORT_WITH_ID.getRoute(report.reportID));
	return;
	}

which will navigate to the report or scroll to bottom of the report. The navigate is executed first which will make the report screen go back to previous report.

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

If the expected solution is to not scroll to bottom after editing the task, we could remove the Report.notifyNewAction after the API.WRITE EDIT_TASK. This could be used for other similar issues.

What alternative solutions did you explore? (1)

If the expected solution involves scrolling to the bottom, we can move the Report.notifyNewAction from Task.ts to TaskDescriptionPage, placing it below Navigation.dismissModal (ensure to check all usages of the editTaskLibrary function).

If scrolling is only necessary when the page report action list does not have the hasNewestReportAction, we can modify the scrollToBottomForCurrentUserAction function so that it does not scroll when there is a hasNewestReportAction. Alternatively, we could pass a parameter to scrollToBottomForCurrentUserAction to determine whether it should scroll when there is no newestReportAction.

What alternative solutions did you explore? (Optional)

To fix the hasNewestReportAction bug (I think it is different bug), we could use add this code in ReportActionList

    const newestVisibleReportAction = sortedVisibleReportActions[0];
    const newestPendingActionTime = useRef(report.lastVisibleActionCreated);
    const newCreatedUserActions = useMemo(() => {
        const previousLastReportAction = ReportActionsUtils.getReportAction(report.reportID, previousLastIndex.current);
        const previousCreatedDate = new Date(previousLastReportAction.created);
        const previousIndex = sortedVisibleReportActions.findIndex((action) => new Date(action.created) < previousCreatedDate);
        const addedActions = sortedVisibleReportActions.slice(0, previousIndex.current === -1 ? -1 : previousIndex - 1);

        const newCreatedActions = addedActions.filter((action) => (action.pendingAction === CONST.RED_BRICK_ROAD_PENDING_ACTION.ADD) && (new Date(action.created) > new Date(newestPendingActionTime.current)));
        if (newCreatedActions.length > 0) {
            newestPendingActionTime.current = newCreatedActions.reduce((a, b) => Math.max(new Date(a.created), new Date(b.created))).created;
        }
        return newCreatedActions;
   },   [lastActionIndex]);

    const hasNewestReportAction = (newCreatedUserActions.length > 0) || (new Date(newestVisibleReportAction?.created) >= new Date(report.lastVisibleActionCreated));

[deetergp]

I think this blocker may be a result of this PR from yesterday's staging deploy #47209