中断コンテキスト内からの潜在的に問題のある暗黙の CoroutineScope レシーバーアクセスを報告します。

When a suspend function or lambda captures an implicit CoroutineScope receiver from the outer context, it might lead to unexpected behavior.

Such code can be prone to violating the rules of Structured Concurrency, even though it might look deceptively well-structured.

This can lead to incorrect behaviors when handling errors, cancelling computations, or managing lifetimes.

A typical example:

fun processFlow(flow: Flow<String>) {
  runBlocking {
    flow.collectLatest {
      
      // launched on this@runBlocking CoroutineScope
      launch { 
        longProcessing(value)
      }
  
    }
  }
}
  
suspend fun longProcessing(value: String) { ... }

In the example above, the launch { ... } call launches coroutines in the implicit CoroutineScope from the outer runBlocking call.

Because of this, collectLatest would not be able to cancel those coroutines when it needs to.

This inspection will detect that launch is called on a CoroutineScope which is captured from the outside of the current suspending lambda (i.e. collectLatest's body).

For more information about this particular problem, see this GitHub Issue.

Possible solutions:

この問題を解決するため、次の操作を実行できます:

• coroutineScope { ... } ビルダーを使用し、suspend 関数のライフサイクルに関連付けられた子スコープを作成する
• Rearrange the code so that the implicit CoroutineScope comes from the current syntactical context

In case you are sure that the code is correct, you can explicitly specify the receiver to make your intention clear. In the example above, that would be this@runBlocking.launch { ... }. Note, however, that in this case the semantics of the code won't change.