[HOLD for payment 2025-01-07] [HOLD for payment 2025-01-02][LHN Mismatch] Move client-only keys from report_ to reportMetadata_

[puneetlath]

We are going to be changing the behavior of OpenApp/ReconnectApp when it does a full reconnect to replace the full reports list that the client has stored instead of merging with it. This means that any client-only data that we have about reports can potentially get wiped when the back-end reconnects.

We already have a reportMetadata_ object in Onyx that is meant to store such data. Let's move any keys that are currently client-only that are stored in the report_ object to the reportMetadata_ object. These are some likely keys that we will need to migrate:

1. avatarFileName: The filename of the avatar.
2. icons: List of icons for report participants.
3. isPolicyExpenseChat: Indicates whether the report is a policy expense chat.
4. lastMessageTimestamp: The timestamp of the last message on the report.
5. lastReadCreated: The time of the last read of the report.
6. openOnAdminRoom: If the admin room should be opened.
7. cachedTotal: Report cached total.
8. lastMessageTranslationKey: Translation key of the last message in the report.
9. isOptimisticReport: Whether the current report is optimistic.
10. displayName: Display name of the report, shown in options and mentions.
11. ownerEmail: E-mail of the report owner.
12. errors: Collection of errors to be shown to the user.
13. isLastMessageDeletedParentAction: Whether the last message was a deleted parent action.
14. iouReportAmount: Total amount of money owed for IOU report.
15. preexistingReportID: The ID of the preexisting report.
16. isHidden: Whether the report is hidden from the options list.
17. isChatRoom: Whether the report is a chat room.
18. participantsList: Collection of participants' personal details.
19. text: Text to be displayed in the options list, which matches reportName by default.
20. privateNotes: Collection of participant private notes, indexed by their accountID.
21. isLoadingPrivateNotes: Whether participants' private notes are currently loading.
22. selected: Whether the report is currently selected in the options list.
23. pendingChatMembers: Pending members of the report.
24. transactionThreadReportID: The ID of the single transaction thread report associated with this report, if one exists.
25. participantAccountIDs: Participant account IDs.
26. visibleChatMemberAccountIDs: Visible chat member account IDs.

To do this we will need to:

1. Confirm whether this is the complete list of keys to migrate or whether there are others
2. Confirm whether these keys all need to exist. Some of them seem like they might potentially be redundant and could be removed altogether. For example, isPolicyExpenseChat and isChatRoom seem like they may be redundant with chatType. The ownerEmail seems like it may be redundant with ownerAccountID. We should check each key and ensure that it's actually needed.
3. For those that are needed, let's move them to reportMetadata_ by:
   a. Updating any code that sets the data to set it in reportMetadata_ instead
   b. Updating any code that gets the data to get it from reportMetadata_ instead
   c. Create migration to migrate any existing data in these keys from report_ to reportMetadata_
4. Let's make it so that people can't accidentally add new client-only keys to the report object. We can do this by adding a unit test that checks that only these keys have been added to the report object. So that it must be explicitly updated if new keys are added after confirming that they are safe to add there

Issue Owner

Current Issue Owner: @muttmuure

[melvin-bot]

Current assignee @puneetlath is eligible for the NewFeature assigner, not assigning anyone new.

[melvin-bot]

⚠️ It looks like this issue is labelled as a New Feature but not tied to any GitHub Project. Keep in mind that all new features should be tied to GitHub Projects in order to properly track external CAP software time ⚠️

[melvin-bot]

Triggered auto assignment to Design team member for new feature review - @dubielzyk-expensify (NewFeature)

[puneetlath]

Confirm whether this is the complete list of keys to migrate or whether there are others

I'll be taking this part since it requires looking at the back-end also.

[TMisiukiewicz]

Hey, Tomasz from Callstack here, I can help with this issue

[puneetlath]

@TMisiukiewicz I need to confirm the full list that we're working with. To start, can you look into:

• Why do we have isPolicyExpenseChat? It seems redundant with type/chatType
• Why do we have isChatRoom? It seems redundant with type/chatType
• Whether there are others in the list above that seem redundant with existing data

[TMisiukiewicz]

@puneetlath I checked this list and seems like majority of these properties are generated in the runtime and describe the options for LHN, not reports directly. Seems like they are not stored in Onyx at all, might the Report type be outdated? I think it'd be good to actually go through the properties defined in a type and verify if they are still used anywhere in the project.

So, I'd say both properties are replaceable by referring to chatType when it comes to LHN options, but I don't see those stuff being moved from report to reportMetadata since they are not stored in Onyx

[puneetlath]

Oh wow, ok that's great to know.

I think it'd be good to actually go through the properties defined in a type and verify if they are still used anywhere in the project.

This makes sense to me. Want to do this as a first step? Basically, raise a PR to update the type with only the things that are actually used by the client.

Also, if the back-end attempts to merge something into Onyx that isn't in the type, do we log that?

[TMisiukiewicz]

This makes sense to me. Want to do this as a first step? Basically, raise a PR to update the type with only the things that are actually used by the client.

yeah sure, I'll start exploring it tomorrow 👍

[TMisiukiewicz]

So i verified all the properties and looks like there is 15 of them that should be possible to remove:

• icons
• lastMessageTimestamp
• lastReadCreated
• isPolicyExpenseChat
• openOnAdminRoom
• displayName
• errors
• isLastMessageDeletedParentAction
• iouReportAmount
• isChatRoom
• participantsList
• text
• selected
• participantAccountIDs
• visibleChatMemberAccountIDs

I’ll remove each unused property along with its references, one at a time, committing after each change to ensure stability.

[puneetlath]

Nice! Sounds good. Perhaps we should break it up into a few different PRs so that it's easier to revert if one of them causes a problem, without needing to revert it all.

[TMisiukiewicz]

Sure, i'll start with a PR with those that are not used anywhere as it's the easiest one

[TMisiukiewicz]

Opened first PR #52182, now I'll move to work on the properties that have some references in the codebase but do not seem to be a part of Report

[melvin-bot]

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

• migrate pendingChatMembers to reportMetadata #54247

If no regressions arise, payment will be issued on 2025-01-07. 🎊

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

• @TMisiukiewicz does not require payment (Contractor)
• @shubham1206agra requires payment (Needs manual offer from BZ)

[melvin-bot]

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

• [@shubham1206agra] Please propose regression test steps to ensure the new feature will work correctly on production in further releases.
• [@muttmuure] Link the GH issue for creating/updating the regression test once above steps have been agreed upon.

[melvin-bot]

Payment Summary

Upwork Job

• Contributor: @TMisiukiewicz is from an agency-contributor and not due payment
• ROLE: @shubham1206agra paid $(AMOUNT) via Upwork (LINK)

BugZero Checklist (@muttmuure)

• 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//hired)
• I have paid out the Upwork contracts or cancelled the ones that are incorrect
• I have verified the payment summary above is correct

[shubham1206agra]

@puneetlath Is there anything else we have to work on here?

[muttmuure]

How many PRs got merged?

[shubham1206agra]

@muttmuure 15 PRs

#52182
#52233
#52247
#52395
#52535
#52619
#52690
#52693
#52773
#52806
#52963
#53203
#53817
#54247
#54295

[muttmuure]

OK cool cool, let me get back to you

[shubham1206agra]

Waiting for payment summary from @muttmuure

[muttmuure]

Happy to call it $2500

I'll also defer to @puneetlath

[muttmuure]

I'm actually headed out on leave, so I will need someone else to pick this one up. @mallenexpensify do you think you could help me out here?

[shubham1206agra]

@muttmuure Can we make this $2500 as there were 15PRs.

[muttmuure]

Cool, I updated my summary. That seems OK to me

[muttmuure]

I'm assigning Matt to ask if he can help me out here

[mallenexpensify]

@shubham1206agra can you please accept the job and reply here once you have?
https://www.upwork.com/jobs/~021890560303637581940

[shubham1206agra]

@mallenexpensify Offer accepted

[mallenexpensify]

Contributor+: @shubham1206agra paid $2500 via Upwork

I'm late to this issue, I'm assuming we don't need test cases (or.. if we do, they're handled elsewhere).
Going to close, thanks @shubham1206agra