try: https://treeherder.mozilla.org/jobs?repo=try&landoInstance=lando-prod-2025&landoCommitID=58670

not blocking for this fix - is it possible to reproduce this lifecycle condition with an ActivityScenario test or something like that, so we can have a test that catches this behavior in the future?

testing-exception-other: this change safely guards against a crash, is unlikely to introduce side effects, and may not be easily testable with a unit test

In D307387#10666124, @jdelorenzo wrote:

not blocking for this fix - is it possible to reproduce this lifecycle condition with an ActivityScenario test or something like that, so we can have a test that catches this behavior in the future?

testing-exception-other: this change safely guards against a crash, is unlikely to introduce side effects, and may not be easily testable with a unit test

Good question! I tried, but it was incredibly tricky to reproduce. You have to be in such as state where we try to do JUST after the fragment gets destroyed. If we injected , I would have been able to advance the clock, while delaying the but it's pretty much impossible to test with the way our code is set up 😅

We could probably also solve it properly by moving things out to a lifecycle observer and injecting Settings, AppStore & pocket stories service (that was how I fixed a leak associated with the top sites in https://phabricator.services.mozilla.com/D246359.
This was just the solution with the smallest blast radius that came to mind without refactoring how the owning team have implemented their work. I can file a follow-up to suggest this approach of using a lifecycle observer.

I filed https://bugzilla.mozilla.org/show_bug.cgi?id=2048364