Redundant 'async' call may be reduced to 'kotlinx.coroutines.withContext'

I have the following code:

DATABASE_CONTEXT.async(block = block).await()

IntelliJ gives me a warning and wants to simplify it to use withContext instead of async.

These two things aren’t exactly equivalent though, right? i.e. if I cancel the coroutine, it will also stop the coroutine code from executing if I user withContext, but if I use DATABASE_CONTEXT.async(block = block).await(), that has a new coroutine hierarchy, and that will ensure that the code inside the block runs to completion, right?

Those are two very important distinctions, and I like to differentiate between the use-cases. The fact that the IDE is suggesting these to me as equivalent seems like an error to me.

[elizarov]

Thanks a lot! It is also good to know that this architecture works well with withContext. As for “wrapping plugin” – we indeed periodically run into cases where this or that kind of wrapping might be needed and some day this kind of “auto-wrapping” might become a separate language feature.

[qwwdfsad]

When I apply the fix IntelliJ suggests, merely saying withContext { jmsconsumer.receive() }, it works, but if the job hierarchy gets cancelled, this one is stuck forever.

It gets stuck anyway, but in case of async you just don’t wait for it on the outer scope. So this behaviour is rather uncovered a potential leak in your code. If JMS supports interruption, I would recommend using runInterruptible to support cooperative cancellation of JMS