Runtime & concurrency
Reveal answer and reasoning
AsyncLocal follows logical execution context rather than one fixed physical thread. An async operation can inherit ambient data, change its own slot, suspend, and resume without requiring a permanent thread identity. The caller's context is restored around the child operation in the lesson, so the child's string assignment does not become the parent's later slot value.
A common wrong answer treats it as one ordinary global variable or assumes matching thread IDs imply the same logical context. It is also not a deep-copy mechanism: a mutable object stored in the slot may still be referenced by parent and child, making object mutation visible through both references. Ambient values can retain large graphs or obscure dependencies, so scope and cleanup need a contract.
Prefer immutable correlation data or explicit arguments where appropriate rather than treating flow propagation as automatic isolation or authorization.
What a strong answer covers
- AsyncLocal follows logical flow, not permanent thread identity.
- Slot replacement differs from shared-object mutation.
- Ambient data still needs scope and lifetime ownership.
Common pitfall
Assuming flow-local assignment implies deep isolation of every referenced object.
Follow-up questions
- What happens with a mutable list stored in the slot?
- When would an explicit argument be clearer?
Self-review
Choose what to revisit. These marks are your own assessment and are separate from lesson completion.