You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
Production screenshot:
Root cause and considerations for proposals:
Image, which handles the load request, is memoized based on whether the identity of the source prop stays the same
ImageWithSizeCalculation is reconstructing source each render because it's creating the object in the prop. Pretty easy to fix with a useMemo instead:
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:
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?
Screenshots/Videos
In development:
receipt404.mov
Production screenshot:

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:This does NOT occur for the
Image/index.native.jsimplementation.View all open jobs on GitHub
Upwork Automation - Do Not Edit