-
Notifications
You must be signed in to change notification settings - Fork 3.7k
Description
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.25-4
Reproducible in staging?: Yes
Reproducible in production?: It's worse on production, the app fails to load completely once I sign in.
If this was caught during regression testing, add the test name, ID and link from TestRail:
Email or phone of affected tester (no customers): lizzi@infinitered.com
Logs: https://stackoverflow.com/c/expensify/questions/4856
Expensify/Expensify Issue URL:
Issue reported by: @lindboe
Slack conversation: https://expensify.slack.com/archives/C01GTK53T8Q/p1705427206739379?thread_ts=1705360862.915459&cid=C01GTK53T8Q
Action Performed:
- Have a request with a receipt image that produces a 404 when requested. (I am not sure how to reproduce this part outside of development, where you can give a thumbnail component an intentionally wrong URL.)
- Open the app in a web browser and open the devtools. Observe that the requests for the image that can't be loaded are continuously made.
Expected Result:
After the request returns a 404, the requests should stop being made.
Actual Result:
Requests for the image are infinitely repeated.
Workaround:
If this issue is encountered in production in its current state, the app can't be used at all, although I believe that particular issue may have been fixed by @cead22.
If this issue is encountered in staging, I don't think this prevents usage.
In development, it causes a connection/file descriptor leak as webpack generates more and more connections it never clears. This eventually leads to the developer's computer encountering errors and not working properly, including affecting internet access. (This must also be caused by a second issue with the app not clearing closed connections correctly).
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
In development:
receipt404.mov
Root cause and considerations for proposals:
Image, which handles the load request, is memoized based on whether the identity of thesourceprop stays the sameImageWithSizeCalculationis reconstructingsourceeach render because it's creating the object in the prop. Pretty easy to fix with auseMemoinstead:
const source = useMemo(() => {
return {uri: url};
}, [url]);
This does NOT occur for the Image/index.native.js implementation.
Upwork Automation - Do Not Edit
- Upwork Job URL: https://www.upwork.com/jobs/~010386784e89b6acc5
- Upwork Job ID: 1749005349524606976
- Last Price Increase: 2024-02-04
- Automatic offers:
- paultsimura | Contributor | 28145121
