```suspend fun debug() { println("${coroutineContext[STreeEvent]}") } fun main() = runBlocking {...

# coroutines

[Exerosis]

suspend fun debug() {
    println("${coroutineContext[STreeEvent]}")
}
fun main() = runBlocking {
    val test = SSubject(0)
    SComponent().apply {
        println("Component: $this")
        println("Test: $test")
        test(this, BEFORE) {
            println("${coroutineContext[STreeEvent]}")
            debug()
        }
...

Can someone help me understand why :

println("${coroutineContext[STreeEvent]}")
            debug()

prints:

null
1212899836

Why on earth would the context change between these two places?

[ephemient]

probably first one is kotlinx.coroutines.CoroutineScope.coroutineContext (on `runBlocking`'s scope) and second one is kotlin.coroutines.coroutineContext

[Exerosis]

😮 why do they shadow eachother?

[Richard Gomez]

@Exerosis What happens if you change debug to:

- suspend fun debug() {
+ suspend fun debug(): Unit = coroutineScope {

[ephemient]

the problem is the other way around, whatever test is doing, it's not passing its newly created scope to its lambda block

[ephemient]

I expect you'd see more consistent results with

coroutineScope {
    println(...)
    debug()
}

[Richard Gomez]

the problem is the other way around,

You're right, I misread that. Long day... 😴

[Joffrey]

It's for this reason that you should avoid coroutineContext when you want the one from the current suspend function, use currentCoroutineContext() instead in this case

[Exerosis]

When do you even want CoroutineScope.coroutineContext? I'm a little confused

[ephemient]

within low-level machinery code - it is a non-suspending way to extract the context of a CoroutineScope, whereas the built-in mechanism only works in suspending context and is actually implemented by compiler magic

[ephemient]

you should not be using either

[Exerosis]

Don't have a huge amount of choice seemingly. But I see the idea now. Thank you!