I've observed that when an async-built-coroutine i...

# coroutines

[julian]

I've observed that when an async-built-coroutine is nested within a launch-built-coroutine, the async-coroutine's job isn't added to the launch-coroutine's job's children. Is this always true?

[julian]

launch { 
    async { ... }
}

[streetsofboston]

According to the structured concurrency, the coroutine of launch should not finish until the coroutine of async has finished.

The job of the async should be a child of launch.

[julian]

Thanks, @streetsofboston.  That's surprising.
So, I can't explain why this (Kotest) test passes:

Untitled.kt

[julian]

I used to believe that the parent-child relationships on which structured concurrency depends is detectable by examining the children of jobs. But, in recent experiments, it seems to be that structured concurrency can be respected without such relationships being evident in the children of the parent jobs involved. The test above is an example of this.

[streetsofboston]

Maybe it's empty because launch has not yet started at all when you assert your test.

If your test is asserted a bit later, the coroutine of the launch may have been started and its job may have a child-job

[streetsofboston]

Then again, advanceUntilIdle should have made sure that the coroutine of launch should at least have started.... But I'm not sure about the exact behavior of advanceUntilIdle...

[julian]

I can try the test again without Kotest.

[julian]

Or... I can assert that both jobs are complete before checking if the outer is empty. Yeah, I'll try that instead.

[julian]

Yup. Same result. Both jobs have completed.

Untitled.kt

[streetsofboston]

Hmmmmm...... Maybe a parent job removes a child-job from its list when that child-job has finished. I'm not sure whether the behavior of a job's list of child-jobs is defined/documented anywhere.

[julian]

I can investigate that by checking at various points what the state of job children is.