[LOW] [Splits] [$500] Incorrect message displayed in LHN after deleting IOU thread messages: showing "This is the beginning of your chat" Instead of "No activity yet"

[m-natarajan]

If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!

---

Action Performed:

1. Open a chat
2. Go to the "Request money"
3. Enter an amount and send the money request
4. Open the IOU for detailed view
5. Send a message within the IOU thread
6. Delete all messages in the IOU thread
7. Check the LHN

   Expected Result:

   Upon deleting all messages from the IOU thread (and the IOU itself), we should hide the IOU thread entirely from the LHN.

   Actual Result:

   Incorrect message displayed in LHN after deleting IOU thread messages: showing "This is the beginning of your chat" Instead of "No activity yet"

   Workaround:

   Unknown

   Platforms:

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

   • [ ] Android / native
   • [ ] Android / Chrome
   • [ ] iOS / native
   • [ ] iOS / Safari
   • [x] MacOS / Chrome / Safari
   • [ ] MacOS / Desktop

Version Number: 1.3.57-3 Reproducible in staging?: Yes Reproducible in production?: Yes 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 Notes/Photos/Videos: Any additional supporting documentation

https://github.com/Expensify/App/assets/38435837/bc69afa7-d723-48bb-8ec3-585aec3a48b7

https://github.com/Expensify/App/assets/38435837/0f889b8e-7748-4493-98e6-af9e12fe1e37

Expensify/Expensify Issue URL: Issue reported by: @ayazhussain79 Slack conversation: https://expensify.slack.com/archives/C049HHMV9SM/p1691789691040869

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~014ccb11728107f0a1
• Upwork Job ID: 1696976805040549888
• Last Price Increase: 2023-09-13

[melvin-bot[bot]]

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

[melvin-bot[bot]]

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

[melvin-bot[bot]]

📣 @ayazhussain79 We're missing your Upwork ID to automatically send you an offer for the Reporter role. Once you apply to the Upwork job, your Upwork ID will be stored and you will be automatically hired for future jobs!

[grgia]

Assigning @rojiphil!

[jjcoffee]

@joekaufmanexpensify Do we need to add the Engineering label for the BE changes?

[rojiphil]

@jjcoffee FE code is ready in PR here. Kindly review. Thanks.

[rojiphil]

@joekaufmanexpensify @grgia Who would be taking care of the BE changes? Also, wanted to know when BE changes are ready so that testing can be completed in FE.

[grgia]

@jjcoffee could you point me to the required BE changes

[jjcoffee]

@grgia We want to be able to call DeleteMoneyRequest when the last comment is deleted on an IOU thread, but currently it fails in the case where the last transaction has already been deleted for the IOU Report (this is as opposed to the case where you delete the transaction first, and then all the comments, which works fine). So ideally we'd remove that restriction so that we can just arbitrarily call DeleteMoneyRequest.

[rojiphil]

@grgia The test video for the failed API request is available here. Hope, that also helps.

[jjcoffee]

@grgia Apologies it looks like I got my terms a bit confused here! DeleteMoneyRequest should only be used for deleting the transaction (or money request) itself, which is why we get the error regarding the missing transactionID. Calling DeleteMoneyRequest when there is only a single transaction on the IOU report just seems to delete the IOU report as a side-effect. To summarise what we're dealing with is this case:

1. Create money request
2. Open IOU report (money request thread)
3. Send a message on the thread
4. Delete money request in the thread
5. Delete the message

The message does get deleted, but the IOU report and reportAction remains, which leaves a 0-value reportAction in the parent report. Switching steps 4 and 5 so that the money request is deleted last, results in the IOU report being deleted (as a side-effect), which is what we want to achieve.

Are you able to check under what condition the IOU report is getting deleted on the BE when calling DeleteMoneyRequest? I think the change we might be actually looking for is calling DeleteComment should delete the IOU report as a side-effect if there are no more reportActions left (other than the CREATED action, I guess!).

[rojiphil]

Are you able to check under what condition the IOU report is getting deleted on the BE when calling DeleteMoneyRequest? I think the change we might be actually looking for is calling DeleteComment should delete the IOU report as a side-effect if there are no more reportActions left (other than the CREATED action, I guess!).

@jjcoffee Confused now. Are we deviating from the proposed solution i.e. using deleteMoneyRequest to delete IOU Report when the last normal comment is deleted? You seem to suggest to use deleteReportComment instead.

[grgia]

@rojiphil could you please outline the required changes in that case

[jjcoffee]

@rojiphil Yes, that makes the most sense to me. Calling deleteMoneyRequest to delete the IOU report doesn't make sense as the only purpose of the function is to delete the transaction, not the IOU report (that's why a transactionID is required). The IOU report only gets deleted as a side-effect of calling deleteMoneyRequest when there's only a transaction in a report.

[rojiphil]

@rojiphil Yes, that makes the most sense to me. Calling deleteMoneyRequest to delete the IOU report doesn't make sense as the only purpose of the function is to delete the transaction, not the IOU report (that's why a transactionID is required). The IOU report only gets deleted as a side-effect of calling deleteMoneyRequest when there's only a transaction in a report.

@jjcoffee In that case, when deleteReportComment is called and if the report type is iou and the deleted comment is the last comment in the report, BE should clear the report as it is done (shown in attached screenshot) for deleteMoneyRequest when the last MoneyRequest was deleted. Is this what we are agreeing to?

[jjcoffee]

@rojiphil Yup that sounds good to me!

[rojiphil]

@jjcoffee And as part of our original proposal, deleteMoneyRequest does the additional work of deleting the report (as side effect) if the deleted Money Request was the last one. I think, since the context is Money Request and not normal comment, it may still be better and easier to fix this in BE as part of handling the DeleteMoneyRequest API request by extending the functionality of deleteMoneyRequest. In this case, we can send an additional variable to the backend isLastCommentDeleted. The BE can check if this flag is set. If it is set and if there is only one comment left in the IOU Report, BE can execute the side effect of deletion of IOU Report without bothering about transaction id. What do you think about this? or would you still prefer the deleteReportComment approach? My only concern with the deleteReportComment approach is that we will have to duplicate the side-effect implementation of deletion of IOU Report there. Let me know what you think.

[jjcoffee]

@rojiphil I really don't think it makes sense to call deleteMoneyRequest when we're not actually deleting a money request, in the same way that it wouldn't make sense to call deleteReportComment if we're actually deleting a money request.

[rojiphil]

Got it. So, we do as we discussed here

The following response is sent by BE when DeleteMoneyRequest API is called as part of deletion of last Money Request from IOU Report. From the BE perspective, the same response is what would be expected fwhen we call DeleteComment API from FE for the deletion of the last comment (and no pending Money Request) in a report of type iou or expense.

@jjcoffee Does BE changes makes sense?

[rojiphil]

@jjcoffee

The previous screenshot was not correct as it was taken during deletion of Money Request from Transaction View. Sorry for that. Have corrected this.

One additional query: As expense report are also a money request report as mentioned here, this change is applicable also for report of type expense. Right?

[jjcoffee]

@joekaufmanexpensify Are you able to confirm if we should have the same expected behaviour for deleting the last comment on an expense report as an IOU report (see @rojiphil's comment)?

[rojiphil]

@rojiphil could you please outline the required changes in that case

@grgia Are the details in this comment sufficient enough for BE changes?

The FE changes are done from my end. So, if your changes are ready, please let me know so that the FE changes can be tested.

[rojiphil]

@grgia The details section of PR here has been updated with the FE changes. Hope that helps too.

[rojiphil]

One additional query: As expense report are also a money request report as mentioned here, this change is applicable also for report of type expense. Right?

@jjcoffee Did some research on the need of inclusion of expense report in our implementation. And, it looks like we have to include expense report due to the following reason: The type of report (i.e. iou or expense) created is decided by a fiag called isPolicyExpenseChat here. Now, both these type of reports creates iou report action (i.e. with type iou) as mentioned here and here. Further, calling deleteMoneyRequest during deletion of an action is only dependent on report action of type iou as shown here which means that this is applicable for both iou and expense reports. So, it is imperative that, for the last comment deletion in deleteReportComment, we should consider both report types i.e. iou and expense.
Does this make sense?

[rojiphil]

@joekaufmanexpensify This is the first time I am handling a case that requires BE change. So, I am curious to know how the compensation is considered here. I was assigned about 4 working days ago but shouldn’t the issue be assigned after BE changes are done? Or am I missing something here?

[jjcoffee]

@rojiphil You can try asking on Slack, but there's no real hard rule here, it's usually down to the issue. In this case I'd expect the compensation countdown to start once the BE changes are done since we can't really test without them. cc @joekaufmanexpensify

[rojiphil]

Thanks @jjcoffee for your reply. Since every issue is handled on a case-by-case basis, I thought it would be better to come to a common ground on this between ourselves than take it to Slack.

[joekaufmanexpensify]

Is it correct that we can't merge the FE changes until the BE are merged? If so, then I don't think we'd penalize you for delays in the merge time related to the BE changes.

[joekaufmanexpensify]

Pending further discussion

[rojiphil]

@joekaufmanexpensify I am not aware of any pending discussion. Or am I missing something here? I think we are waiting for BE changes to be ready.

[grgia]

cc @rojiphil @jjcoffee @joekaufmanexpensify Unfortunately I am unable to prioritize this PR this week. I will get changes up next week after I am home from our company event.

This was my mistake, but in the future if there are ANY backend changes required as part of a proposal, let's make the issue internal, even if there are FE changes.

Again, this was my bad and I appreciate all the work that's been put into this discussion. I will update the title to remind myself to look at this next week. Thank you for your patience

[joekaufmanexpensify]

No worries at all, thanks for the update @grgia ! Just to make sure my understanding is correct, we'll still have @rojiphil handle the frontend changes here, right? Just after you complete the backend PR next week? I'm thinking yes, but want to be sure.

[joekaufmanexpensify]

I think Georgia plans to get the backend PR up this week

[joekaufmanexpensify]

Pending internal PR

[joekaufmanexpensify]

Same

[joekaufmanexpensify]

Still pending internal PR. @grgia thinking you'll loop around to this one after wave 8 stuff is done. Is that right?

[joekaufmanexpensify]

Still pending internal PR

[joekaufmanexpensify]

Same

[joekaufmanexpensify]

Same.

[joekaufmanexpensify]

Same

[joekaufmanexpensify]

No update.

[joekaufmanexpensify]

@grgia think you'll be able to get back to this one anytime soon? Feels like this bug could fit into the wave 5 category.

[joekaufmanexpensify]

Thinking about it more, I think this one fits with #vip-split. Raised there!

[grgia]

Going to release this on- see https://github.com/Expensify/App/issues/25930#issuecomment-1723045379 for guidance

[joekaufmanexpensify]

I think this just needs someone working on vip-split to pick up the BE portion

[joekaufmanexpensify]

Same

[joekaufmanexpensify]

Still waiting for BE assignee

[joekaufmanexpensify]

Paused

[joekaufmanexpensify]

Same

[joekaufmanexpensify]

Paused