Repository navigation
iOS - Profile - The App crashes when saving the user's avatar #37963
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.49-0
Reproducible in staging?: y
Reproducible in production?: n
If this was caught during regression testing, add the test name, ID and link from TestRail: https://expensify.testrail.io/index.php?/tests/view/4410248
Issue reported by: Applause - Internal Team
Action Performed:
- Open iOS App
- Login with any account
- Go to Account Settings
- Tap to User Avatar
- Select "Upload photo"
- Select "Take photo" or "Choose from gallery"
- Take/select photo and tap "Save"
Expected Result:
Photo was successfully saved as the user's avatar.
Actual Result:
App crashes after user taps on "Save" button
Workaround:
Unknown
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
Add any screenshot/video evidence
Activity
github-actions commentedon Mar 8, 2024
👋 Friendly reminder that deploy blockers are time-sensitive ⏱ issues! Check out the open `StagingDeployCash` deploy checklist to see the list of PRs included in this release, then work quickly to do one of the following:
kbecciv commentedon Mar 8, 2024
We think that this bug might be related to #vip-vsb
@quinthar
melvin-bot commentedon Mar 8, 2024
Triggered auto assignment to @madmax330 (
Engineering), see https://stackoverflowteams.com/c/expensify/questions/9980/ for more details.shubham1206agra commentedon Mar 8, 2024
@kbecciv Can you share the crash logs here?
kbecciv commentedon Mar 8, 2024
@shubham1206agra Please attached
logs crash.docx
roryabraham commentedon Mar 8, 2024
not able to reproduce on dev
roryabraham commentedon Mar 8, 2024
this appears to be related to this crash, which was first caught on 1.4.47-10. So I'm not sure if it's a blocker (but it was my mistake not noticing this earlier this week, I had been looking only at Android crashes by mistake)
roryabraham commentedon Mar 8, 2024
was able to reproduce on staging. I wonder if it has to be an HEIC?
roryabraham commentedon Mar 8, 2024
need to test on a physical device...
22 remaining items
roryabraham commentedon Mar 10, 2024
reopening to verify the fix in 1.4.49-4
situchan commentedon Mar 10, 2024
ok so as I said here, app still crashes on launch for the users who already triggered crash on avatar upload in previous build.
They should uninstall and reinstall to continue using the app.
roryabraham commentedon Mar 10, 2024
yeah, that's unfortunate but I don't think there's anything we can do about it really☹️
roryabraham commentedon Mar 10, 2024
well, maybe if we found a "restorative" fix to the crash rather than a "preventative" fix, but idk if we'll be able to do that since it seems to be a low-level crash in the native network request code, presumably caused by some bad url or something?
roryabraham commentedon Mar 10, 2024
verified this is fixed after you uninstall and reinstall
kosmydel commentedon Mar 11, 2024
Hey, I've investigated this issue today.
The reason behind it was that we were passing the
base64=nullparam inside thefileparameter when calling the API:App/src/libs/actions/PersonalDetails.ts
Line 385 in 95a774e
The
RCTNetworkingnetworking library didn't like thebase64nullish value, and early returned causing the crash:https://github.com/facebook/react-native/blob/a7fde7c885a3827c03b058a21023b18501e2a57a/packages/react-native/Libraries/Network/RCTNetworking.mm#L425-L428
Why did we pass the
base64value?The
expo-image-manipulatorlibrary by default sets thebase64option to false, meaning that we don't need to generate it. But the library instead of skipping this param, addsbase64=nullin this line:https://github.com/expo/expo/blob/a05bfbc3a907177bca2dd8a2dd22073763daa895/packages/expo-image-manipulator/ios/ImageManipulatorModule.swift#L33
Commenting out this line fixes the problem.
So I come up with two solutions (without touching the library):
base64: trueoption to generate the base64 (instead of passing null)base64prop from the parameters when calling the API command:I will also contact with the internal expo maintainers at SWM, as they might want to fix it in the library.
I will prepare a PR with the fix tomorrow.
Thanks @roryabraham for the initial investigation, as it helped a lot!
roryabraham commentedon Mar 11, 2024
sounds good @kosmydel and thanks for figuring that out. Glad my initial investigation was helpful! If we're not using the base64 encoding I imagine it's likely better not to generate it unnecessarily. So let's go with the 2nd solution to remove the
base64from the parameters when calling the API command.Alternatively, maybe we can update expo-image-manipulator to remove
base64: nullfrom the response if nobase64encoding is created. That seems like the best solution if they're down for thatkosmydel commentedon Mar 12, 2024
I've contacted an Expo maintainer, so I will keep you updated.
For now, I think to unblock the issue, I can prepare a PR with the 2nd solution.
kosmydel commentedon Mar 13, 2024
Quick update: After contacting Expo maintainers they told me, that this is expected, and consistent across other parameters. They will improve the types, so the
base64will also include thenulltype (currently it isstring | undefined). So in that way, we would know, thatbase64could be null, and we would be able to handle it appropriately.For now, I've created a PR with 2nd solution.