[$500] LHN - Task name not displayed in chat preview in LHN after re-logging

[izarutskaya]

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.13-4
Reproducible in staging?: Y
Reproducible in production?: Y
If this was caught during regression testing, add the test name, ID and link from TestRail:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Expensify/Expensify Issue URL:
Issue reported by: Applause-Internal Team
Slack conversation: @

Action Performed:

1. Open the app and log in
2. Navigate to any chat
3. Assign a task
4. Log out
5. Log in to the same account or as another user with whom the task was shared

Expected Result:

The task name is displayed in the chat preview in LHN as the last message

Actual Result:

Only "Task for" is displayed until the chat is opened

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

Bug6314571_1702646639077.video_2023-12-14_15-06-02.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~01dfcd1e43b6e247d3
• Upwork Job ID: 1735655732066258944
• Last Price Increase: 2023-12-15

[melvin-bot]

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

[melvin-bot]

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

[melvin-bot]

Bug0 Triage Checklist (Main S/O)

• This "bug" occurs on a supported platform (ensure Platforms in OP are ✅)
• This bug is not a duplicate report (check E/App issues and #expensify-bugs)
  • If it is, comment with a link to the original report, close the issue and add any novel details to the original issue instead
• This bug is reproducible using the reproduction steps in the OP. S/O
  • If the reproduction steps are clear and you're unable to reproduce the bug, check with the reporter and QA first, then close the issue.
  • If the reproduction steps aren't clear and you determine the correct steps, please update the OP.
• This issue is filled out as thoroughly and clearly as possible
  • Pay special attention to the title, results, platforms where the bug occurs, and if the bug happens on staging/production.
• I have reviewed and subscribed to the linked Slack conversation to ensure Slack/Github stay in sync

[melvin-bot]

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

[FitseTLT]

Proposal

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

Task name not displayed in chat preview in LHN after re-logging

What is the root cause of that problem?

The root cause lies in here

App/src/libs/TaskUtils.ts

Lines 46 to 47 in 8bef4bb

	const taskReportID = reportAction?.childReportID ?? '';
	const taskTitle = getTaskTitle(taskReportID, reportAction?.childReportName);

Until the report is opened by the user the reportAction has neither childReportID nor childReportName so getTaskTitle is returning an empty string.

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

In getLastMessageTextForReport the TaskUtils.getTaskCreatedMessage should only be opted whenever the report action in this case has childReportID or childReportName otherwise we should fallback to the lastMessageText of the report.
So change this

App/src/libs/OptionsListUtils.js

Lines 418 to 419 in 8bef4bb

	} else if (ReportActionUtils.isCreatedTaskReportAction(lastReportAction)) {
	lastMessageTextFromReport = TaskUtils.getTaskCreatedMessage(lastReportAction);

to

    } else if (ReportActionUtils.isCreatedTaskReportAction(lastReportAction) && (lastReportAction?.childReportName || lastReportAction?.childReportID)) {

What alternative solutions did you explore? (Optional)

[namhihi237]

Proposal

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

The name of the task on the LHN is not correct when re-login

What is the root cause of that problem?

When we first log in, we get the empty title of the task here because we dont have a childReportID, Until we open the report

App/src/libs/TaskUtils.ts

Lines 45 to 49 in ab138ee

	function getTaskCreatedMessage(reportAction: OnyxEntry<ReportAction>) {
	const taskReportID = reportAction?.childReportID ?? '';
	const taskTitle = getTaskTitle(taskReportID, reportAction?.childReportName);
	return Localize.translateLocal('task.messages.created', {title: taskTitle});
	}

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

Since we updated the method to get the title of the task here we want to translate it.
So we can update the logic get the taskReportID.

const taskReportID = reportAction?.childReportID ?? (reportAction as OriginalMessageAddComment)?.originalMessage?.taskReportID ?? '';

What alternative solutions did you explore? (Optional)

N/A

[abdulrahuman5196]

Hi, Will review today.

[dylanexpensify]

TY! @abdulrahuman5196 what's our findings?

[abdulrahuman5196]

Re-checking again now

[abdulrahuman5196]

@namhihi237 's proposal here #33165 (comment) looks good and works well.

For some reason, the childReportID is not populated during initial OpenApp api call, but populated after OpenReport API call. But the taskReportID is present in originalMessage of the reportAction even after OpenApp API call, so the above frontend fix is also working.

We can also fix it in backend by making sure childReportID is being populated.
But I think frontend fix is enough for now, anyways will let the internal engineer confirm on this as well.

🎀 👀 🎀
C+ Reviewed

[melvin-bot]

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

[marcaaron]

Hmm, I think I disagree with the recommended proposal as it does not seem like it would fix the problem.

When we first log in, we get the empty title of the task here because we dont have a childReportID, Until we open the report

It does sound like a backend issue.

For some reason, the childReportID is not populated during initial OpenApp api call, but populated after OpenReport API call. But the taskReportID is present in originalMessage of the reportAction even after OpenApp API call, so the above frontend fix is also working.

Ok but that's a problem because now the title is getting populated two different ways. Which way is the right way? Let's pick one and make sure it works vs. having various fallbacks and workarounds.

cc @thienlnam

[namhihi237]

@marcaaron currently in the originalMessage we always has a taskReportID if the reportAction is task. So i think we can only use it from here

[marcaaron]

Ok, but which one is the correct one to use? @thienlnam maybe has the answer... let's wait and see.

[thienlnam]

Hmm I think this was broken recently - historically we had it populate either the task report or the reportAction because if you never open the task report, you don't ever have the task report fetched.

We've made a lot of BE changes but every task change should now also update the parent reportAction and if not we should make sure to update that flow. So because the scenario where you can have someone that never opens the task report and therefore never gets those task pusher updates, we should use the reportAction data

[namhihi237]

@thienlnam We use reportAction data here but in this case, When the task has the last reportAction as CreatedTaskReportAction we want to get the taskReportID to get the title. And we consider 2 ways. Use
reportAction.childReportID or get from originalMessage. Currently reportAction.childReportID In case of re-login it does not return data childReportID so can we get originalMessage? Can you confirm this

[thienlnam]

We should probably update the BE so it always returns the childReportID

[namhihi237]

@thienlnam Here we use the condition in originalMessage to check whether the created report action is created.

App/src/libs/ReportActionsUtils.ts

Lines 612 to 614 in 7b836cf

	function isCreatedTaskReportAction(reportAction: OnyxEntry<ReportAction>): boolean {
	return reportAction?.actionName === CONST.REPORT.ACTIONS.TYPE.ADDCOMMENT && !!reportAction.originalMessage?.taskReportID;
	}

And we use it in a few places, like here:

App/src/libs/OptionsListUtils.js

Lines 419 to 420 in 7b836cf

	} else if (ReportActionUtils.isCreatedTaskReportAction(lastReportAction)) {
	lastMessageTextFromReport = TaskUtils.getTaskCreatedMessage(lastReportAction);

That's why I think why we should consistently use it to get the taskReportID in getTaskCreatedMessage , what do you think?

[melvin-bot]

@marcaaron, @abdulrahuman5196, @dylanexpensify Whoops! This issue is 2 days overdue. Let's get this updated quick!

[thienlnam]

Updating the priority as it's not by any means urgent

[melvin-bot]

@thienlnam @abdulrahuman5196 @dylanexpensify this issue is now 3 weeks old. There is one more week left before this issue breaks WAQ and will need to go internal. What needs to happen to get a PR in review this week? Please create a thread in #expensify-open-source to discuss. Thanks!

[dylanexpensify]

@thienlnam do we think this fits in #vip-vsb?

[thienlnam]

Yeah, this could be a good low polish for vip-vsb

[melvin-bot]

@thienlnam @abdulrahuman5196 @dylanexpensify this issue is now 4 weeks old and preventing us from maintaining WAQ, can you:

• Decide whether any proposals currently meet our guidelines and can be approved as-is today
• If no proposals meet that standard, please take this issue internal and treat it as one of your highest priorities
• If you have any questions, don't hesitate to start a discussion in #expensify-open-source

Thanks!

[melvin-bot]

Current assignee @abdulrahuman5196 is eligible for the Internal assigner, not assigning anyone new.

[dylanexpensify]

added appropriate designation

[dylanexpensify]

no movement

[dylanexpensify]

Same as last week.

[dylanexpensify]

same

[thienlnam]

Thoughts on closing this? Doesn't seem valuable to work on at this time