Fix crash when Exit event is fired multiple times

[JorgeMucientes]

Exit event could potentially be fired more than once, which will make the app crash because it will attempt to navigate back more than once, leading to "IllegalStateException FragmentManager is already executing transactions"

Closes: #13226
Closes: #13289

Description

Tentative fix for crash:

IllegalStateException: FragmentManager is already executing transactions
    at com.woocommerce.android.ui.products.variations.VariationDetailFragment.setupObservers$lambda$24(VariationDetailFragment.kt:320)
    is Exit -> requireActivity().onBackPressedDispatcher.onBackPressed()
    at com.woocommerce.android.ui.products.variations.VariationDetailFragment.$r8$lambda$6j_9a98nQXRa_5YR2Y_XIxTyzTw(VariationDetailFragment.kt:0)
    at com.woocommerce.android.ui.products.variations.VariationDetailFragment$$ExternalSyntheticLambda14.invoke(VariationDetailFragment:0)
    at com.woocommerce.android.ui.products.variations.VariationDetailFragment$sam$androidx_lifecycle_Observer$0.onChanged(VariationDetailFragment.kt:0)
    at com.woocommerce.android.viewmodel.MultiLiveEvent.observe$lambda$0(MultiLiveEvent.kt:43)
    observer.onChanged(t)

And for the crash:

java.lang.IllegalStateException: FragmentManager is already executing transactions
    at androidx.fragment.app.FragmentManager.ensureExecReady(FragmentManager.java:1937)
    at androidx.fragment.app.FragmentManager.execPendingActions(FragmentManager.java:1996)
    at androidx.fragment.app.FragmentManager.handleOnBackPressed(FragmentManager.java:862)
    at androidx.fragment.app.FragmentManager$1.handleOnBackPressed(FragmentManager.java:570)
    at androidx.activity.OnBackPressedDispatcher.onBackPressed(OnBackPressedDispatcher.kt:276)

Which has a similar stack trace.

I spent some time trying to replicate the crash but I was unable to. My hypothesis is that the Exit event is triggered simultaneously from VariationDetailViewModel when the user clicks the back button and when loadVariation function fails to load the variation and automatically runs: triggerEvent(Event.Exit). I tried using APIFaker to make different api calls fail when opening variation detail but wasn't able to reproduce the race condition where 2 Exit events are fired at once.

The proposed solution is to basically make sure we unsubscribe from LiveData as soon as the first Exit event is fired, so that any subsequent call to triggerEvent(Event.Exit) will be ignored.

Testing information

Open a product with variations and check that everything works as expected:

• Add new variation works as expected
• Opening variation detail and navigating back and forth works as expected
• Deleting variation works as expected
• Tap on the three dots menu and update several variations in bulk. Check everything works as expected

The tests that have been performed

The above

• I have considered if this change warrants release notes and have added them to RELEASE-NOTES.txt if necessary. Use the "[Internal]" label for non-user-facing changes.

Reviewer (or Author, in the case of optional code reviews):

Please make sure these conditions are met before approving the PR, or request changes if the PR needs improvement:

• The PR is small and has a clear, single focus, or a valid explanation is provided in the description. If needed, please request to split it into smaller PRs.
• Ensure Adequate Unit Test Coverage: The changes are reasonably covered by unit tests or an explanation is provided in the PR description.
• Manual Testing: The author listed all the tests they ran, including smoke tests when needed (e.g., for refactorings). The reviewer confirmed that the PR works as expected on big (tablet) and small (phone) in case of UI changes, and no regressions are added.

[wpmobilebot]

📲 You can test the changes from this Pull Request in WooCommerce-Wear Android by scanning the QR code below to install the corresponding build.

	App Name	WooCommerce-Wear Android
	Platform	⌚️ Wear OS
	Flavor	Jalapeno
	Build Type	Debug
	Commit	792072c
	Direct Download	woocommerce-wear-prototype-build-pr13281-792072c.apk

[wpmobilebot]

📲 You can test the changes from this Pull Request in WooCommerce Android by scanning the QR code below to install the corresponding build.

	App Name	WooCommerce Android
	Platform	📱 Mobile
	Flavor	Jalapeno
	Build Type	Debug
	Commit	792072c
	Direct Download	woocommerce-prototype-build-pr13281-792072c.apk

[codecov-commenter]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 40.79%. Comparing base (9218fa9) to head (792072c).
Report is 57 commits behind head on trunk.

Additional details and impacted files

@@             Coverage Diff              @@
##              trunk   #13281      +/-   ##
============================================
- Coverage     40.79%   40.79%   -0.01%     
  Complexity     6411     6411              
============================================
  Files          1353     1353              
  Lines         77679    77679              
  Branches      10692    10692              
============================================
- Hits          31690    31689       -1     
- Misses        43182    43183       +1     
  Partials       2807     2807              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[irfano]

I couldn’t reproduce the issue either, and I’m not sure this will fix it because I didn’t notice the root cause being the invocation of .onBackPressed() twice. There could be other reasons triggering a fragment manager transaction, but it’s worth trying. LGTM! 👍🏻

[JorgeMucientes]

Thanks for the review @irfano

I didn’t notice the root cause being the invocation of .onBackPressed() twice. There could be other reasons triggering a fragment manager transaction, but it’s worth trying.

Hmm, that's a good point. However, from the code in those fragments experiencing the crash, I see only two events that would lead to a fragment transaction to be executed: Exit and ExitWithResult. And Exit is the only one I see with the potential to be fired twice or more.
But it is also true that looking at the breadcrumbs from Sentry for these crashes, the crash happens when the app is restored from the background. And sometimes, while the app is in the background, the device runs into Low memory. Which makes me less confident no this fix will resolve the crash :( In any case as you mentioned I think its worth trying the tentative fix and see how the crash rate is impacted.