| 11:25 | <Andreu Botella> | I was updating my engine262 implementation, and I noticed that a side effect of https://github.com/tc39/proposal-async-context/pull/41 was that FinalizationRegistry callbacks don't propagate the context anymore |
| 11:52 | <Justin Ridgewell> | Because it doesn’t do a default HostMakeJobCallback anymore? |
| 11:53 | <Justin Ridgewell> | Shouldn’t this be capturing the context at register anyways? |
| 11:59 | <Andreu Botella> | we made it so HostCallJobCallback doesn't set the snapshot, instead leaving that to NewPromiseReactionJob and NewPromiseResolveThenableJob, which are of course not called on FinalizationRegistry callbacks |
| 14:59 | <Mathieu Hofman> | I always expected the finalization registry callback to capture the time the corresponding registry entry was added. |
| 15:01 | <Mathieu Hofman> | Afaik this and atomics are the only 2 APIs with custom scheduling logic, and atomics ends up using a promise |
| 15:05 | <Andreu Botella> | I always expected the finalization registry callback to capture the time the corresponding registry entry was added. |
| 16:52 | <littledan> | OK, sounds like we all agree on the bug fix, and there isn't any controversy. Does this need an engine262 change, or also a spec change? |
| 17:02 | <Mathieu Hofman> | Sounds like it needs a spec change to capture and restore the context for finalization registry jobs? |
| 18:15 | <Justin Ridgewell> | Yup |
| 18:18 | <Justin Ridgewell> | Though, we also need to fix Atomis.waitAsync's rejection context |