At shutdown we synchronously drain the dispatcher. In the dispatcher may be one or more submit() calls. These submissions are processed synchronously, so the db has indeed made sure that (barring disk IO failures) there's a ping that's ready for upload at some nebulous "later".

However it then triggers upload which spawns a thread to handle upload.

Triggering asynchronous tasks during a synchronous shutdown is probably not a good idea. If it even successfully starts before the process exits, it might make assumptions about the SDK's ability to do stuff. And even if it's aware that the SDK can no longer be considered initialized, it's the uploader: what state is the network stack in?

I think we should make trigger_upload shutdown-aware. At the very least it can decide to not even try to upload stuff after shutdown. But what might be even better is if it checks if there's at least one upload task it can send off during shutdown (synchronously).

:chutten: with all the Glean progress that's landed, is this still an issue?

The inciting incident for this has been taken care of with recent block-(but not for too long)-at-shutdown changes, you're right.