{"id":689112,"date":"2026-03-19T11:00:58","date_gmt":"2026-03-19T10:00:58","guid":{"rendered":"https:\/\/blog.jetbrains.com\/?post_type=idea&p=689112"},"modified":"2026-03-19T11:01:05","modified_gmt":"2026-03-19T10:01:05","slug":"intellij-idea-s-new-kotlin-coroutine-inspections-explained","status":"publish","type":"idea","link":"https:\/\/blog.jetbrains.com\/pt-br\/idea\/2026\/03\/intellij-idea-s-new-kotlin-coroutine-inspections-explained","title":{"rendered":"IntelliJ IDEA’s New Kotlin Coroutine Inspections, Explained"},"content":{"rendered":"\n

This article was written by an external contributor.<\/em><\/p>\n\n\n

\n
\n
\n
\n \"\"\n <\/div>\n
\n

Marcin Moska\u0142a<\/h4>\n

Marcin is a highly experienced developer and Kotlin instructor, founder of Kt. Academy, an official JetBrains partner specializing in Kotlin training. He is also a Google Developers Expert and a well-known contributor to the Kotlin community. Marcin is the author of several widely recognized books, including Effective Kotlin<\/em>, Kotlin Coroutines<\/em>, Functional Kotlin<\/em>, Advanced Kotlin<\/em>, Kotlin Essentials<\/em>, and Android Development with Kotlin<\/em>.<\/p>\n

Website<\/a><\/p>\n <\/div>\n <\/div>\n <\/div>\n <\/div>\n\n\n\n

Every technology has its misuses, and different ecosystems use different approaches to prevent them. In the Kotlin ecosystem, I believe the philosophy has always been to make APIs so good that correct usage is simple and intuitive, while misuse is harder and more complicated. This differs from JavaScript, which has plenty of legacy practices (like using == instead of ===, or var<\/code> instead of let\/const<\/code>) and relies more on warnings. However, not everything can be enforced by good design, and Kotlin also uses warnings to guide developers in writing better code. <\/p>\n\n\n\n

Today, IntelliJ IDEA introduces a set of new inspections for the Kotlin coroutines library. I\u2019ve seen these issues in many codebases and addressed them through my books, articles, and workshops. These patterns often show up, so let\u2019s walk through why they are problematic and how to handle them correctly. <\/p>\n\n\n\n

Note: These inspections are also available in Android Studio. You can check how IntelliJ IDEA versions map to Android Studio versions here<\/a>. <\/p>\n\n\n\n

awaitAll()<\/code>and joinAll()<\/code><\/h2>\n\n\n\n

Available since IntelliJ IDEA 2025.2<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

If you use map { it.await() }<\/code>, IntelliJ IDEA will suggest awaitAll()<\/code>. If you use forEach { it.join() }<\/code>, it will suggest joinAll()<\/code>. Why? These alternatives are cleaner, and awaitAll()<\/code> is also more efficient and better represents waiting for multiple tasks, as it waits for all elements concurrently rather than one after another. <\/p>\n\n\n\n

awaitAll()<\/code> also behaves more efficiently in the presence of exceptions. Imagine awaiting 100 coroutines, and the fiftieth throws an exception. awaitAll()<\/code> will immediately rethrow the exception, unlike map { it.await() }<\/code>, which would wait for the first 49 coroutines before throwing the exception. In most cases, this behavior cannot be observed because of other exception propagation mechanisms. <\/p>\n\n\n\n

currentCoroutineContext()<\/code> over coroutineContext<\/code><\/h2>\n\n\n\n

Available since IntelliJ IDEA 2025.2<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

All suspending functions can access the context of the coroutine in which they are called. Traditionally, this was done via the coroutineContext<\/code> property. The problem is that CoroutineScope<\/code>, which is implicitly available in coroutine starters, such as launch, coroutineScope<\/code>, and runTest<\/code>, has a property with the same name. This can be confusing and lead to issues. Consider the following example: <\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

This code tests the mapAsync<\/code> function and checks whether it correctly propagates context from the caller to the transformation. It is incorrect. Within the transformation, we could read the caller context from the coroutineContext<\/code>, but not in this situation. This lambda is defined inside runTest<\/code>, and the coroutineContext<\/code> property from CoroutineScope<\/code> (provided by runTest<\/code>) takes priority over the top-level coroutineContext<\/code> property. This kind of mistake is quite common, which is why the currentCoroutineContext()<\/code> function was introduced to read the context of the coroutine that runs a suspending function. You should use it instead of coroutineContext<\/code>. <\/p>\n\n\n\n

runBlocking<\/code> inside a suspending function<\/h2>\n\n\n\n

Available since IDEA 2025.2<\/p>\n\n\n\n

Using runBlocking<\/code> inside suspending functions is a serious issue. It blocks the calling thread, which defeats the purpose of coroutines.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

So what can you use instead? That depends on what you want to achieve. In most cases, you don\u2019t need it. If you need to create a coroutine scope, use coroutineScope { \u2026 }<\/code>. If you need to change context, use withContext(ctx) { \u2026 }<\/code>.
Watch out for situations where a suspending function calls a regular function that uses runBlocking. Opt for making this function suspend to avoid making a blocking call. <\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Unused Deferred<\/code><\/h2>\n\n\n\n

Available since IntelliJ IDEA 2025.3<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

This inspection appears when you use async without ever using its result. In such cases, you should use launch instead. This is the key difference between launch and async<\/code>: async<\/code> returns a result and is expected to await this result, while launch<\/code> produces no result. <\/p>\n\n\n\n

Because of this, exception handling differs. async<\/code> doesn\u2019t call CoroutineExceptionHandler<\/code> because it is expected to throw an exception from await and propagate it this way. <\/p>\n\n\n\n

Job<\/code> used as an argument in a coroutine starter<\/h2>\n\n\n\n

Available since IntelliJ IDEA 2025.3<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

I\u2019ve been looking forward to this inspection for years! Using Job<\/code> as an argument to a coroutine starter causes issues, and it\u2019s something I\u2019ve seen in many projects. I covered this anti-pattern in my book and workshops, but it still appears quite often. This inspection should help clarify the correct approach. Let\u2019s look at why Job<\/code> shouldn\u2019t be used as an argument for a coroutine. <\/p>\n\n\n\n

The key misunderstanding here is that Job<\/code> cannot be overridden by an argument. If you use any other context, it will be used in the coroutine and its children, but not Job<\/code>. Every coroutine creates its own job. A job contains a coroutine\u2019s state and relations \u2013 it cannot be shared or enforced from outside. The Job<\/code> that is used as an argument isn\u2019t going to be a job of this coroutine. Instead, it overrides Job<\/code> from the scope and becomes a parent. This breaks structured concurrency.<\/p>\n\n\n\n

For example: Using withContext(SupervisorJob()) { \u2026 }<\/code> behaves very differently from supervisorScope { \u2026 }<\/code>. <\/p>\n\n\n\n

supervisorScope<\/code> creates a child coroutine of the caller of this function, and it uses a supervisor job (it doesn\u2019t propagate its children\u2019s exceptions). On the other hand, withContext(SupervisorJob())<\/code> creates a regular coroutine, which is a child of SupervisorJob<\/code> and has no relation to the caller. <\/p>\n\n\n\n

Consider the code below. An exception in the first launch propagates to withContext<\/code> (which uses regular Job<\/code>), cancels the other child coroutines, and is then rethrown. SupervisorJob()<\/code> has no effect. In some cases, it can even be harmful, as it breaks structured concurrency. If the caller of withContext(SupervisorJob())<\/code> is cancelled, that cancellation won\u2019t propagate, which will result in a memory leak. <\/p>\n\n\n\n

import kotlinx.coroutines.*\n\nval handler = CoroutineExceptionHandler { _, e ->\n\u00a0\u00a0\u00a0println(\"Exception:\u00a0 ${e.message}\")\n}\n\nfun main(): Unit = runBlocking(handler) {\n\u00a0\u00a0\u00a0\/\/ DON'T DO THAT!\n\u00a0\u00a0\u00a0withContext(SupervisorJob()) {\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0launch {\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0delay(1000)\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0throw Error(\"Some error\")\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0}\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0launch {\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0delay(2000)\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0println(\"AAA\")\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0}\n\u00a0\u00a0\u00a0}\n\u00a0\u00a0println(\"Done\")\n}\n\/\/ (1 sec)\n\/\/ Exception in thread \"main\"...<\/pre>\n\n\n\n
\"\"<\/figure>\n\n\n\n
Using supervisorScope<\/code> would prevent this problem: <\/p>\n\n\n\n
import kotlinx.coroutines.*\n\nval handler = CoroutineExceptionHandler { _, e ->\n\u00a0\u00a0\u00a0println(\"Exception:\u00a0 ${e.message}\")\n}\n\nfun main(): Unit = runBlocking(handler) {\n\u00a0\u00a0supervisorScope {\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0launch {\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0delay(1000)\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0throw Error(\"Some error\")\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0}\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0launch {\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0delay(2000)\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0println(\"AAA\")\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0}\n\u00a0\u00a0}\n\u00a0\u00a0println(\"Done\")\n}\n\/\/ (1 sec)\n\/\/ Exception:\u00a0 Some error\n\/\/ (1 sec)\n\/\/ AAA\n\/\/ Done<\/pre>\n\n\n\n
A Job<\/code> used as an argument breaks the relationship with the caller. In the case below, updateToken<\/code> won\u2019t be related to the caller of getToken<\/code>:<\/p>\n\n\n\n
suspend fun getToken(): Token = coroutineScope {\n\u00a0\u00a0\u00a0val token = tokenRepository.fetchToken()\n\u00a0\u00a0\u00a0launch(Job()) { \/\/ Poor practice\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0tokenRepository.updateToken(token)\n\u00a0\u00a0\u00a0}\n\u00a0\u00a0\u00a0token\n}<\/pre>\n\n\n\n
This is generally discouraged, as it breaks structured concurrency. The standard approach would be to sequentially call updateToken<\/code>: <\/p>\n\n\n\n
suspend fun getToken(): Token {\n\u00a0\u00a0\u00a0val token = tokenRepository.fetchToken()\n\u00a0\u00a0\u00a0tokenRepository.updateToken(token)\n\u00a0\u00a0\u00a0return token\n}<\/pre>\n\n\n\n
If we really want to detach updateToken<\/code> from getToken<\/code>, a better practice would be to start the launch on a different scope, like the backgroundScope we define in our application for background tasks. With this approach, the new coroutine is still attached to a scope, just a different one: <\/p>\n\n\n\n
suspend fun getToken(): Token {\n\u00a0\u00a0\u00a0val token = tokenRepository.fetchToken()\n\u00a0\u00a0\u00a0backgroundScope.launch { \/\/ Acceptable\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0tokenRepository.updateToken(token)\n\u00a0\u00a0\u00a0}\n\u00a0\u00a0\u00a0return token\n}<\/pre>\n\n\n\n
suspendCancellableCoroutine<\/code> instead of suspendCoroutine<\/code><\/h2>\n\n\n\n
Available since IntelliJ IDEA 2025.3<\/p>\n\n\n\n
\"\"<\/figure>\n\n\n\n
To suspend a coroutine, use suspendCancellableCoroutine<\/code>. Its predecessor, suspendCoroutine<\/code>, does not support cancellation and should be avoided.
suspendCancellableCoroutine<\/code> is a low-level API rarely used in application code, but often used by libraries that support suspending calls. <\/p>\n\n\n\n
Suspicious implicit CoroutineScope<\/code> receiver<\/h2>\n\n\n\n
Available since IntelliJ IDEA 2025.3, but this inspection is disabled by default and must be enabled manually.<\/p>\n\n\n\n
\"\"<\/figure>\n\n\n\n
Implicit receivers within lambdas can be confusing. In the above example, async<\/code> calls are executed on the scope created by coroutineScope<\/code> because collectLatest<\/code> doesn\u2019t provide its own scope. This can lead to memory leaks. When a new value reaches collectLatest<\/code>, it should cancel processing of the previous one. In this example, it cannot cancel the async<\/code> coroutines, as they are attached to coroutineScope<\/code>, not to collectLatest<\/code>. To avoid this, define coroutineScope<\/code> inside collectLatest<\/code>, not outside it. This inspection highlights such cases to prevent these issues. <\/p>\n\n\n\n
\"\"<\/figure>\n\n\n\n
Simpler operations for flow processing<\/h2>\n\n\n\n
Available since IntelliJ IDEA 2026.1 (currently in EAP)<\/p>\n\n\n\n
\"\"<\/figure>\n\n\n\n
You may already know these from collection or sequence processing:
If you use filterNotNull<\/code> after map, you\u2019ll get the suggestion to use mapNotNull<\/code>. If you use filter { it is T }<\/code>, the IDE will suggest using filterNotNull<T><\/code>.
These suggestions are now also available for flows! <\/p>\n\n\n\n
Summary<\/h2>\n\n\n\n
IntelliJ IDEA continues to help you write better code \u2013 not only by advancing its AI tools and agents, but also by improving the core development experience. There are still many inspections I would love to see in the IDE, but the current set already brings significant value.<\/p>\n","protected":false},"author":1138,"featured_media":689378,"comment_status":"closed","ping_status":"closed","template":"","categories":[4113],"tags":[6850,756,21],"cross-post-tag":[],"acf":[],"_links":{"self":[{"href":"https:\/\/blog.jetbrains.com\/pt-br\/wp-json\/wp\/v2\/idea\/689112"}],"collection":[{"href":"https:\/\/blog.jetbrains.com\/pt-br\/wp-json\/wp\/v2\/idea"}],"about":[{"href":"https:\/\/blog.jetbrains.com\/pt-br\/wp-json\/wp\/v2\/types\/idea"}],"author":[{"embeddable":true,"href":"https:\/\/blog.jetbrains.com\/pt-br\/wp-json\/wp\/v2\/users\/1138"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.jetbrains.com\/pt-br\/wp-json\/wp\/v2\/comments?post=689112"}],"version-history":[{"count":10,"href":"https:\/\/blog.jetbrains.com\/pt-br\/wp-json\/wp\/v2\/idea\/689112\/revisions"}],"predecessor-version":[{"id":690091,"href":"https:\/\/blog.jetbrains.com\/pt-br\/wp-json\/wp\/v2\/idea\/689112\/revisions\/690091"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/blog.jetbrains.com\/pt-br\/wp-json\/wp\/v2\/media\/689378"}],"wp:attachment":[{"href":"https:\/\/blog.jetbrains.com\/pt-br\/wp-json\/wp\/v2\/media?parent=689112"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.jetbrains.com\/pt-br\/wp-json\/wp\/v2\/categories?post=689112"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.jetbrains.com\/pt-br\/wp-json\/wp\/v2\/tags?post=689112"},{"taxonomy":"cross-post-tag","embeddable":true,"href":"https:\/\/blog.jetbrains.com\/pt-br\/wp-json\/wp\/v2\/cross-post-tag?post=689112"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}