[$250] Chat - RBR displayed on the wrong expense preview component for a few seconds
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: 9.0.57-0 Reproducible in staging?: Y Reproducible in production?: Y Issue was found when executing this PR: https://github.com/Expensify/App/pull/51782 Email or phone of affected tester (no customers): [email protected] Issue reported by: Applause Internal Team
Action Performed:
- Navigate to staging.new.expensify.com
- Create a workspace
- Submit a manual expense
- Submit a scan expense with a picture that will through an error
- Wait for the scan to be finished and open the report conversation
Expected Result:
RBR shown only on the failed scan expense
Actual Result:
RBR shown on the manual expense at first for a few seconds
Workaround:
Unknown
Platforms:
- [x] Android: Standalone
- [x] Android: HybridApp
- [x] Android: mWeb Chrome
- [ ] iOS: Standalone
- [ ] iOS: HybridApp
- [ ] iOS: mWeb Safari
- [x] MacOS: Chrome / Safari
- [ ] MacOS: Desktop
Screenshots/Videos
https://github.com/user-attachments/assets/9101993f-9986-48d4-9e24-992ee4a726eb
Upwork Automation - Do Not Edit
- Upwork Job URL: https://www.upwork.com/jobs/~021854987328786203223
- Upwork Job ID: 1854987328786203223
- Last Price Increase: 2024-11-22
Issue Owner
Current Issue Owner: @
Triggered auto assignment to @MitchExpensify (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details. Please add this bug to a GH project, as outlined in the SO.
The cause of RBR is from data of BE API. The first transaction has this violation tag called cashExpenseWithNoReceipt:
[info] [Report] Handled multipleEvents event sent by Pusher -
...
{"transactionViolations_3345000142618413242":null,
"transactionViolations_8239222946581758013":[{"data":null,"name":"cashExpenseWithNoReceipt","type":"notice"}]}}],"eventType":"onyxApiUpdate"}],"lastUpdateID":2800591071,"previousUpdateID":2800591070}""
I think if there is no reason to send cashExpenseWithNoReceipt by opening the thread, then the violation should not be sent. The code may be in BE API.
Job added to Upwork: https://www.upwork.com/jobs/~021854987328786203223
Triggered auto assignment to Contributor-plus team member for initial proposal review - @c3024 (External)
@MitchExpensify, @c3024 Uh oh! This issue is overdue by 2 days. Don't forget to update your issues!
Looks like this should be an internal issue. I will check and update.
π£ It's been a week! Do we have any satisfactory proposals yet? Do we need to adjust the bounty for this issue? πΈ
The cause of RBR is from data of BE API. The first transaction has this violation tag called
cashExpenseWithNoReceipt:[info] [Report] Handled multipleEvents event sent by Pusher - ... {"transactionViolations_3345000142618413242":null, "transactionViolations_8239222946581758013":[{"data":null,"name":"cashExpenseWithNoReceipt","type":"notice"}]}}],"eventType":"onyxApiUpdate"}],"lastUpdateID":2800591071,"previousUpdateID":2800591070}""I think if there is no reason to send
cashExpenseWithNoReceiptby opening the thread, then the violation should not be sent. The code may be in BE API.
@jacobkim9881
Which request is returning the response with that transaction violation?
It is an update from GetMissingOnyxMessages request which is the result from waiting for identifying scan.
The order is like:
Submitted Scan expense -> Scanning -> An update from BE called GetMissingOnyxMessages request -> The transaction transactionViolations data has cashExpenseWithNoReceipt error -> Scanfinished
@MitchExpensify @c3024 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!
@MitchExpensify, @c3024 Uh oh! This issue is overdue by 2 days. Don't forget to update your issues!
@jacobkim9881
Thanks for the explanation.
@MitchExpensify
This needs a backend fix. So, this should be internal.
π£ It's been a week! Do we have any satisfactory proposals yet? Do we need to adjust the bounty for this issue? πΈ
@MitchExpensify, @c3024 Uh oh! This issue is overdue by 2 days. Don't forget to update your issues!
I thought labeling internally would assign someone, checking with @mallenexpensify
@c3024 can you please add "π π π C+ reviewed" to assign an engineer to confirm this is a backend issue? Thanks
@MitchExpensify, @c3024 Eep! 4 days overdue now. Issues have feelings too...
π π π
Triggered auto assignment to @carlosmiceli, see https://stackoverflow.com/c/expensify/questions/7972 for more details.
@carlosmiceli, @MitchExpensify, @c3024 Eep! 4 days overdue now. Issues have feelings too...
@carlosmiceli Can you help us confirm if this is a backend issue and recommend next steps please?
Yeah, finally having time to pick this up today, will report back! π
@jacobkim9881 @c3024 I'm not convinced that this is a BE issue. I may be wrong, but this seems like correct behavior (the first transaction has no violation and the second one does). Shouldn't a failed scan actually send a violation?
What I think it's happening is that the FE is applying the RBR to all grouped transactions, or maybe all the report transactions, despite only one having violations. Here's what I'm seeing in dev when the first transaction is created successfully and we throw the second with the scan:
1- First RequestMoney (no violations)
2- Second RequestMoney (failed)
3- Both transactions have the RBR in the workspace (this is the actual issue, right @IuliiaHerets ?):
4- Opening the expense report (looks correct):
Looking at this, I don't see a BE problem, but I may be wrong. If you still believe it to be a BE issue, please elaborate further what type of response would fix this issue and how.
Current assignee @c3024 is eligible for the External assigner, not assigning anyone new.
Re-adding the external label because I'd be interested in seeing FE proposals in the meantime.
Any updates here? @c3024 @jacobkim9881
@MitchExpensify I noticed we haven't gotten proposals since re-adding the External label, why do you think that may be?
@carlosmiceli
The first transaction has this violation tag called cashExpenseWithNoReceipt
I think there is a reason with cashExpenseWithNoReceipt tag on the first transaction. We could let manual transactions not have RBR for the tag from client app.
@jacobkim9881 did you read this: https://github.com/Expensify/App/issues/51989#issuecomment-2513524492 ?
@carlosmiceli We could let the manual transaction not have RBR for cashExpenseWithNoReceipt error but I think the transaction should not get the error from the response.
@mallenexpensify We haven't gotten a response from @c3024 in over a week, how can we reassign this to another C+?