GlobalScope @DelicateCoroutinesApi in kotlinx.coroutines 1.3.x: Choosing the Right CoroutineScope for Lifecycle‑Bound Work

GlobalScope marked @DelicateCoroutinesApi

Starting with kotlinx.coroutines 1.3.x, the library annotates GlobalScope as @DelicateCoroutinesApi, signalling that fire‑and‑forget launches are leak‑prone because they are never cancelled by a lifecycle. The documented mitigation is to use structured concurrency: create a CoroutineScope tied to a lifecycle and cancel its Job during teardown.

Unresolved Scope Decision

While the docs present both a plain Job and a SupervisorJob for lifecycle scopes, they do not prescribe which to use. A plain Job cancels all children on a single failure, potentially harming resilience, whereas SupervisorJob isolates failures but may leave orphaned children if not cancelled correctly.

Cancellation Cooperativity Issue

Even with structured concurrency, a CPU‑bound coroutine that never reaches a suspension point will not stop when its scope is cancelled unless it explicitly checks isActive or calls ensureActive(). This nuance can leave hidden leaks despite the scope being properly cancelled.

Questions

• Should we prefer a plain Job or SupervisorJob for a lifecycle‑bound CoroutineScope in Android to mitigate leaks while preserving failure isolation?
• Is there a reliable way to force cancellation of a CPU‑bound coroutine that never suspends?
• Can we enable a compiler option that automatically flags or cancels such non‑suspending loops?