Now, the fact that this wrapping would make a handful of existing use cases impossible is clearly a problem, and points to why we need some way to access the causing context, rather than just the registration context. This could be as simple as a AsyncContext.Snapshot.noWrap that would prevent any automatic wrapping (or other implicit snapshot restoration that the VM would do via abstract operations), though it's not clear to me whether this would (or should!) provide the non-restoring async/await behavior (vs. just affecting what context callbacks are entered with the first time).

Whould you mind expanding on the distinguishing of child-of and follow-from? All promise resolutions are scheduled asynchronously, it seems to me that in this case "child-of" would be meaning-less in promise's case

where can I read more about that pile of hacks? (maybe you already wrote about it somewhere?)

I hope it's not necessary either, but I can see how Ste{v,ph}en's points argue for it to be necessary. (I'm having trouble understanding what you're supposed to do with currentContext besides reconstruct this array)

The "don't bind around await" case feels a lot like "just use a global variable" to me. To my mind, automatic binding around await is basically one of the main purposes of AC, so if you're not doing that, what are you gaining? Is it just the question of restoring context after awaiting an already-done promise? Assuming all awaited promises were pending when the await kicked off, then a simple model seems like doing nothing would "just work" since the continuation would follow immediately afterwards, so the global value would be correct. Of course this breaks down when the await doesn't actually have to wait - and maybe also when two independent jobs are running interleaved?

So a global variable is obviously a bit too naive to work, but where I'm struggling is to understand how an AC.Variable with mutable state falls short? That seems like it would address the issue of interleaved independent tasks, at least, and since (within the same task) you're presumably not clobbering the actual container variable, then that part shouldn't need to change after an await (and if it did, it could presumably be communicated back upstream). ISTR Stephen mentioning performance concerns, but it's important to compare this against the performance cost of additional overhead needed to maintain a more complex graph, or more different kinds of state that need extra work to fork/join.

To Stephen's point about rewriting code from callbacks to promise/await, I agree that they should be consistent, but I'd argue that it's a transient issue. Callback-based code should be updated to wrap the callbacks so that the behavior is the same. I understand that the fact that ALS has existed for a while with the other behavior makes this a bit of a problem... Ideally the standard Node APIs would have all been updated to wrap/bind when ALS first came out, before anyone began depending on the non-wrapping behavior.

Do OTel implementations in any other language with async/await make this distinction properly? If so it would be great to be able to refer to their implementation strategies.

Yes, basically every other language flows this way with OTel, but other languages also provide things like bytecode manipulation so it's able to do this externally. With Node.js there is no solution.

Bytecode manipulation isn’t magic; I would be surprised if we can’t do what’s achieved with it

Much of the code we need to patch to do that in JS is not reachable at runtime. With bytecode you can manipulate everything, even private things.

handleRequest((req, res) => {
  // ROOT SPAN0
  connection.query('SELECT 1 + 1 AS two') // SPAN1
    .then(a => {
      // PROPOSED CONTEXT: SPAN1.2
      // If the context.variable at this point is SPAN1.2, how do we determine
      // child-of or follow-from?
      // As proposed this should be a follow-from SPAN1.3 instead of SPAN2
      return connection.query('SELECT 2 + 2 AS four') // SPAN2
    })
    .then(b => {
      // PROPOSED CONTEXT: SPAN3.2
      res.writeHead(200, { 'Content-Type': 'text/plain' })
      res.end(a[0].two + b[0].four)
    })
})

function connectionQuery(query) {
  // Current Context: SPANx
  return makeFirstRequest() // SPANx.1
    .then(() => {
      makeSecondRequest() // SPANx.2
    })
}

In the middle of a promise chain, it reads to me that the proposed solution needs to depends on additional cost to determine a child-of relationship now

Sounds good, so can a language runtime, which is what we are talking about changing. It would help us to have a concrete reference point even if it is external/messy

I'll have to talk to my team about that and see what examples I can get from them as I'm really not he expert on other languages. 😅

Again, I'm unclear what the decimal point thing is about here?

Generally to get child-of edges, don’t you want restore after await? Sync is not enough.

What do you mean “flows out to”?

yeah, so in a promise chain, child-of is no longer effective (only the first of a promise chain is sync) and I'm curious about how you create a graph with nesting semantics.

I mean the context flows up to some execution barrier where the JS-side work to be done on the scheduling side is done. With a promise, this is generally when the resolve happens. But if it's a native promise or something like that then none of the resolving stage happens within JS so you just follow the flow back upward until you get to a point in the causal that was in JS, which is when the original call happened.

in JS code that creates a promise and then resolves it, wouldn't this only be the case if there are no AsyncContext.Snapshot.p.run along the promise resolution path?

but in cases like this, wouldn't this mess up tracing?

async function someFunctionYouCareAboutTracing() {
	const response1 = await fetch(...);
	await someAPI();  // this empties out the context after the await!
	const response2 = await fetch(...);
	return await doSomethingWith(response1, response2);
}

maybe this isn't something worth worrying about, but someone might be using snapshots to do things around their AsyncContext.Variables not realizing that that might affect the context in which their promise gets resolved, which would affect other use libraries that use AsyncContext

APMs (unfortunately) fairly often use AsyncResource to "fix" context management flows, but then we break other vendors because we change the graph they were expecting. 😬