[$500] Split Bill - Group members disappeared in a split bill when make second split bill in a row

[lanitochka17]

If you haven’t already, check out our contributing guidelines for onboarding and email [email protected] to request to join our Slack channel!

---

Version Number: 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: Slack conversation:

Issue found when executing PR https://github.com/Expensify/App/pull/29996

Action Performed:

1. Open https://staging.new.expensify.com/
2. Create a group chat with about 3-4 members
3. Send a message to the chat
4. Create a split bill with all members
5. Create a second split bill in a row with the same members

Expected Result:

User should be able to make a two split bills in a row in a group chat

Actual Result:

Group members disappeared in a split bill when make second split bill in a row

Workaround:

Unknown

Platforms:

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

• [x] Android: Native
• [x] Android: mWeb Chrome
• [x] iOS: Native
• [x] iOS: mWeb Safari
• [x] MacOS: Chrome / Safari
• [x] MacOS: Desktop

Screenshots/Videos

Add any screenshot/video evidence

https://github.com/Expensify/App/assets/78819774/f0bb027b-ae52-42d7-ac16-1be4190e2d8d

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~01d3ed805fe8e7116d
• Upwork Job ID: 1738267582378926080
• Last Price Increase: 2024-01-19

Issue Owner

Current Issue Owner: @abdulrahuman5196

[melvin-bot[bot]]

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

[melvin-bot[bot]]

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

[melvin-bot[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[bot]]

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

[adriancova]

Proposal

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

Draft view for a new split bill is getting reset when creating a second split bill right after another.

What is the root cause of that problem?

I've managed to reproduce the issue by throttling my network, root cause is that part of the onyx successData is setting TRANSACTION_DRAFT as null.

{
      onyxMethod: Onyx.METHOD.MERGE,
       key: `${ONYXKEYS.COLLECTION.TRANSACTION_DRAFT}${CONST.IOU.OPTIMISTIC_TRANSACTION_ID}`,
       value: null,
}

So when the network call finishes and we got a new split bill in progress it gets reset.

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

Remove the TRANSACTION_DRAFT merge to null from the successData inside IOU.createSplitsAndOnyxData method

What alternative solutions did you explore? (Optional)

Instead of removing the transaction_draft, we can move it to the optimisticData, though it shouldn't be necessary since the transaction draft view is already cleaned up after submitting it.

Edit: removed reminder text

[alexpensify]

@abdulrahuman5196 - when you get a chance, can you review if this proposal will fix this issue? Thanks!

Heads up, I will be offline from Friday, December 22, to Thursday, January 4, 2024. I will not be actively watching over this GitHub during that period. If anything urgent is needed here, please ask for help in the #expensify-open-source Slack Room-- thanks!

[dukenv0307]

Proposal

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

Group members disappeared in a split bill when make second split bill in a row

What is the root cause of that problem?

We clear the transactionDraft in successData here. So if we create another split bill before the API is complete, this is removed and then group members are cleared.

https://github.com/Expensify/App/blob/7b836cfcee79084177191e3dfb4a927698b09eb4/src/libs/actions/IOU.js#L1235

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

1. I think instead of using the const transactionID when creating a new request, we can generate a random transactionID by using NumberUtils.rand64() and then use it as the ID of the new transaction when we confirm to create it. This is the same way as we do for reportID.

https://github.com/Expensify/App/blob/7b836cfcee79084177191e3dfb4a927698b09eb4/src/pages/home/sidebar/SidebarScreen/FloatingActionButtonAndPopover.js#L204

And then we can replace CONST.IOU.OPTIMISTIC_TRANSACTION_ID with this transactionID.

2. To clear the old draft transaction, when we initialize the transaction draft we can add an extra field like expired which is 30 days (the days can be discussed in the PR) after the current date. Then whenever we open the app, we will call clearOldTransactionDraft function. This function will clear all transactions draft which has expired is less than the current date.

https://github.com/Expensify/App/blob/8e2fb675389bb84deee4b8e001a536252883e72f/src/libs/actions/IOU.js#L140

Here is the test branch: https://github.com/dukenv0307/App/tree/fix/33518

What alternative solutions did you explore? (Optional)

For point 2, we can always clear all transaction drafts whenever we open the App. Although it's not good for the case user is starting the money request flow in another tab, this case is rare and we don't need to take care of this so much.

[melvin-bot[bot]]

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

[melvin-bot[bot]]

@alexpensify, @abdulrahuman5196 Huh... This is 4 days overdue. Who can take care of this?

[melvin-bot[bot]]

📣 It's been a week! Do we have any satisfactory proposals yet? Do we need to adjust the bounty for this issue? 💸

[abdulrahuman5196]

Sorry for the delay. Will check in my morning.

[abdulrahuman5196]

Reviewing now

[abdulrahuman5196]

@dukenv0307 On proposal here https://github.com/Expensify/App/issues/33518#issuecomment-1868906093, it might not be that easy to replace the OPTIMISTIC_TRANSACTION_ID, it seems to be used in multiple checks. Could you kindly update your proposal to see if all cases can be handled?

@adriancova on proposal here https://github.com/Expensify/App/issues/33518#issuecomment-1867998289, do you suggest to not clear the draft data? I am not sure if that would be a valid fix, since the stale data will be present in that case.

[abdulrahuman5196]

Tagging @tgolen, as he made the original change. Could you kindly let us know if there is any specific reason to have the optimistic transaction id as constant OPTIMISTIC_TRANSACTION_ID, since it could overlap with other transactions if we created multiple optimistic transaction of same report?

[dukenv0307]

@abdulrahuman5196 https://github.com/dukenv0307/App/tree/fix/33518 Here is the change, of course we will need to re-test this carefully in the PR, this branch is the detail of the main ideal.

[tgolen]

since it could overlap with other transactions if we created multiple optimistic transaction of same report

My first thought is that if this is happening, this is wrong. There should never be multiple draft transactions for the same report. Then I thought about the case where you want to create multiple requests while being offline, and maybe that's where my logic breaks down.

The reason for having OPTIMISTIC_TRANSACTION_ID was the following:

• An easy way to detect if a transaction is a draft or not. In early versions of my PR this was necessary because the draft was stored in the TRANSACTIONS collection with all other transactions. Halfway through the PR, this was moved to the TRANSACTIONS_DRAFT collection, which solved part of the problem.
• I really wanted to stay away from a lot of flags on the transaction object that aren't used anywhere in the display logic (such as the isNewTransaction property that @dukenv0307 is proposing). Though, this is more of a theoretical problem and not an actual problem.
• Prevent the draft collection from filling up with draft data for infinity. Part of the problem I see with the changes @dukenv0307 is proposing is there is no way to clean up partial drafts (ie. drafts that were abandoned before the save button was clicked).

Ideally, it would be nice if the draft transaction ID was random, but we still need to figure out a way to clean up all the abandoned data so it doesn't keep growing. Maybe this could be solved with an Onyx migration that always removes the X oldest drafts?

[dukenv0307]

@tgolen

Thank for your response

1. isNewTransaction is added to replace the condition transactionID !== CONST.IOU.OPTIMISTIC_TRANSACTION_ID

2. To clear the transaction draft if we close the modal without saving, we can create a wrapper component for iou step and in this component we will clear the transaction draft if this component is umounted without saving.

[tgolen]

Point 1 makes sense. For point 2, why is that any different than what we have today?

[dukenv0307]

If we create the transaction, the draft is already cleared in successData, so we only need to cover the case the user close the request flow without saving.

[mvtglobally]

Issue not reproducible during KI retests. (First week)

[tgolen]

@dukenv0307 Sorry for the confusion, let me be a little more clear about what I mean.

1. Currently, the IOURequestStepStartPage.js clears out the draft transaction when it's unmounted
2. In your draft changes, you commented that out
3. Then you said you are going to put it into a wrapper component

My question is:

• Why does it need to be in a wrapper component and why can't it remain as it is today?

[dukenv0307]

The problem is if we are not in start page and close the modal, is the transaction draft is cleared?

[tgolen]

When I was originally testing it, the start page was mounted the entire time the right-hand-modal was open. It was unmounted anytime the modal was closed (tapped outside of) from any step.

[dukenv0307]

Thanks for your testing. So for point 2 we can use this cleanup function to clear the draft and when we create a transaction, it will be cleared in successData. It is solved now right?

[tgolen]

Unfortunately, there are still a few other flows where the draft collection could fill up with drafts. Primarily, if the app is killed or the tab is closed while the modal is open. This was avoidable when all the drafts used the same optimistic ID. Again, the only way I can think of cleaning those up is to have an onyx migration that cleans out drafts older than X days (maybe 30 days).

[alexpensify]

@tgolen - trying to catch up from being OOO, are you suggesting that we keep this open to find that solution or should I take this to the Open Source room for more discussion? Thank you!

[tgolen]

I think we should keep this open and find a solution to that as part of this issue. I would like to see in incorporated into a proposal.

[melvin-bot[bot]]

📣 It's been a week! Do we have any satisfactory proposals yet? Do we need to adjust the bounty for this issue? 💸

[melvin-bot[bot]]

@alexpensify @abdulrahuman5196 this issue was created 2 weeks ago. Are we close to approving a proposal? If not, what's blocking us from getting this issue assigned? Don't hesitate to create a thread in #expensify-open-source to align faster in real time. Thanks!

[melvin-bot[bot]]

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