Make Glean init in Kotlin fully async #672
Conversation
| // the @MainThread decorator and the `assertOnUiThread` call. | ||
| MainScope().launch { | ||
| ProcessLifecycleOwner.get().lifecycle.addObserver(gleanLifecycleObserver) | ||
| } |
There was a problem hiding this comment.
Do we need to do this here, or could we do it outside of the coroutine (near the top where things like applicationContext are set?)
There was a problem hiding this comment.
I'm not sure yet, I don't think there's anything preventing us from moving it there, before the glean init even starts.
The only two reasons for not doing that would be:
- we don't want to register this if the glean init fails;
- we really want to test this in Fenix before making a call!
There was a problem hiding this comment.
Fair enough on both points. I think I was just coming at it from the angle of -- going off the main thread only to come back to it is more complicated. But, as you say, we don't really know until we try it in the context of Fenix.
There was a problem hiding this comment.
I'll make sure to try that first once I get rid of the failing test and have a proper Fenix build for testing!
There was a problem hiding this comment.
I tested that, but I think we should retain the current behaviour even just to make sure that we don't mistakenly register observers if init fails. Thoughts?
Note that this would also protect us against sudden/immediate going to background while initializing.
There was a problem hiding this comment.
That's a good point about not registering if we exit early for some other error during init. 👍 on this, then!
Dexterp37
force-pushed
the
faster_init
branch
2 times, most recently
from
588d246
to
9d7eadf
Compare
Our test code relies on `withTimeout*` and `while(true)` in a few places to wait for things to happen. However, having a timeout is not enough: if the coroutine is busy, even if the timeout elapses, the work will not be interrupted. That's because cancellation in Kotlin coroutines is cooperative, see [the docs](https://github.com/Kotlin/kotlinx.coroutines/blob/master/docs/cancellation-and-timeouts.md#cancellation-is-cooperative) for more details. This commit uses cooperative cancellation so that tests will break, instead of hanging forever.
Without the context, the Glean init would throw an exception which would "hang" the dispatchers in the next async tests.
Dexterp37
force-pushed
the
faster_init
branch
from
fddbb8c
to
6f1fd24
Compare
Dexterp37
changed the title
I tested this both using Fenix and the Glean SDK sample app: this seem to work as expected. Accumulated data is correctly accounted for and any pre-init dispatched piece of information is sent.
This PR additionally fixes some weird bugs we had in our testing code that made our tests hang forever under certain circumstances. Se the indivudual commit messages.
TODO
flushQueuedInitialTasksimplies