Currently, a few of our drop implementations spawn new tasks to do cleanup work: Cursor, SessionCursor, ClientSession, GridFsUploadStream.

If these objects still exist when the async runtime exists, an issue as described here can arise if the cleanup tasks have not already been spawned at the time the runtime is dropped and begins shutting down, since the runtime will not allow creating new tasks at that point. This is problematic since it prevents the cleanup behavior from occurring; in the case of cursors that cleanup is killing the cursor server-side and for sessions it is aborting an open transaction, if one exists.

We think a route forward here could be to pre-create cleanup tasks during initialization of these types, and have the cleanup tasks wait on a oneshot channel to proceed with cleanup. The drop implementations can then send a value to the channel. Since the task already exists when the runtime is dropped, it will finish before shutdown (unless the user calls shutdown_timeout or shutdown_background, which we should add documentation warning users against).

We should use a similar approach to fix RUST-1437 and pre-create a task for the purpose of sending endSessions when the client is dropped.