| 10:54 | <littledan> | Yes, I think we should specify that, at the top level of the module, it's always a host-provided context (not necessarily empty--the host can put things there) and not based on what dynamic import triggered it (which would be racy) |
| 10:55 | <littledan> | in some super high level way, this is 'registration time' rather than 'call time' (it's the context of the module registry, not the dynamic import) |
| 17:18 | <Steve Hicks> | The empty use case is definitely hypothetical - I see it as a possible counterexample to Daniel's axiom that we should never use the root/empty context if there's any possible non-empty one available. The race condition for dynamic imports is interesting, and I think it speaks to a more general principle that registration context just generally tends to be less racy than causal context. That said, despite the raciness, I think it's still important to be able to access the causal context on-demand, even if it's not the context that's exposed by default. |
| 17:19 | <Steve Hicks> | I assume that would maybe apply to module loading just as well as anything else? If we're going with the approach of adding a causal context property to the event object, would that translate to adding a property to import.meta? |
| 17:20 | <Steve Hicks> | (and if so, would you also expect it to be usable in function scopes? that would keep the causal context alive unexpectedly longer) |
| 18:09 | <littledan> | I assume that would maybe apply to module loading just as well as anything else? If we're going with the approach of adding a causal context property to the event object, would that translate to adding a property to import.meta? |
| 19:45 | <Steve Hicks> | I guess my point is that I'd still rather have it hung on AsyncContext.callingContext, which would limit the lifetime better. |