| 01:54 | <Steve Hicks> | It's mostly the latter - we have some very limited client-side monitoring today via explicit tracer propagation, but we've found it to be difficult for a few reasons: it's easy to forget to pass the tracer along, or to use it improperly, and it's viral, requiring every function signature to adapt to pass it along, so it's impractical to adopt in products that aren't already using it. Our experience with server languages is that it really needs to be implicit, so that's why we're really interested in AsyncContext, and are experimenting with building out some new reporting systems based on that approach. To that end, we're certainly not looking for "exposing everything that goes on" - but we do need to make sure that we can integrate the tracing system into the framework at all, which we know is going to require avoiding registration-time snapshotting in at least some userland APIs, and possibly also some builtins. |
| 01:58 | <Steve Hicks> | I have a PR for the spec infra for the |
| 02:00 | <Steve Hicks> | oh wait, I think I see - it's modifying the version that's already in the proposal... |
| 02:00 | <Steve Hicks> | which doesn't have that section at all yet |
| 02:00 | <Steve Hicks> | Is there an easy way to see it as a diff from the current standard? |
| 02:01 | <Andreu Botella> | the rendered spec has the differences with the current standard as red and green <ins> and <del> sections |
| 02:02 | <Andreu Botella> | you can check out the PR and do npm run build |
| 02:05 | <Steve Hicks> | Does anything else AsyncContext-related live in the Agent Record at this point? I don't think it's a problem, but I've been casually implementing the spec in my spare time and so far haven't touched the Agent Record yet (and at this point I've got almost the entire core language done, with just most of the runtime libraries missing). |
| 02:07 | <Steve Hicks> | (and to answer my own question - yes... AsyncContextMapping lives there) |
| 05:24 | <snek> | does anyone have info on how many ALS variables tend to be in use in applications that do make use of them? my assumption atm is not very many but I'd love hard data. |
| 11:13 | <littledan> | oh yeah I thought we'd use the execution context to hold this kind of thing |
| 11:14 | <littledan> | does anyone have info on how many ALS variables tend to be in use in applications that do make use of them? my assumption atm is not very many but I'd love hard data. |
| 16:10 | <Stephen Belanger> | 10+ is not uncommon, but more than 100 would be very rare. For the most part there’s a single store for each observability project, which often people have a couple installed, and then one in most routing frameworks, which there’s generally not more than one or two of installed. Sometimes companies build their own internally, which I don’t have numbers for how many instances they use internally there, but would assume similarly using a single store for their purpose. |
| 16:11 | <littledan> | I agree that >100 should be rare--it'd generally be a bug. I want to make sure we're considering React Context-type stuff in our analyses though. |
| 16:39 | <Andreu Botella> | Since we're thinking of exposing the causal/originating context as a nullable property on event objects, we should pick a property name |