-
Notifications
You must be signed in to change notification settings - Fork 301
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add TraceEventInfo for TraceItem #1248
Add TraceEventInfo for TraceItem #1248
Conversation
CLA Assistant Lite bot All contributors have signed the CLA ✍️ ✅ |
I have read the CLA Document and I hereby sign the CLA |
This work is to ultimately support a wrangler tail session on a tail worker - without a differentiating Additionally, the question remains as to whether the |
15c1e56
to
4f802d1
Compare
When tailing a tail worker, messages previously had a null event property. Following cloudflare/workerd#1248, these events have a valid event, specifying which scripts produced events that caused your tail worker to run. As part of rolling this out, we're filtering out tail events in the internal tail infrastructure, so we control when these new messages are forward to tail sessions, and can merge this freely. One idiosyncracy to note, however, is that tail workers always report an "OK" status, even if they run out of memory or throw. That is being tracked and worked on separately.
When tailing a tail worker, messages previously had a null event property. Following cloudflare/workerd#1248, these events have a valid event, specifying which scripts produced events that caused your tail worker to run. As part of rolling this out, we're filtering out tail events in the internal tail infrastructure, so we control when these new messages are forward to tail sessions, and can merge this freely. One idiosyncracy to note, however, is that tail workers always report an "OK" status, even if they run out of memory or throw. That is being tracked and worked on separately.
When tailing a tail worker, messages previously had a null event property. Following cloudflare/workerd#1248, these events have a valid event, specifying which scripts produced events that caused your tail worker to run. As part of rolling this out, we're filtering out tail events in the internal tail infrastructure, so we control when these new messages are forward to tail sessions, and can merge this freely. One idiosyncracy to note, however, is that tail workers always report an "OK" status, even if they run out of memory or throw. That is being tracked and worked on separately.
4f802d1
to
a76cbb1
Compare
this probably needs to hold a sec, we probably want to change "traces" per product decisions |
d4ebb9c
to
921020a
Compare
Updated to change This is now ready to go |
When tailing a tail worker, messages previously had a null event property. Following cloudflare/workerd#1248, these events have a valid event, specifying which scripts produced events that caused your tail worker to run. As part of rolling this out, we're filtering out tail events in the internal tail infrastructure, so we control when these new messages are forward to tail sessions, and can merge this freely. One idiosyncracy to note, however, is that tail workers always report an "OK" status, even if they run out of memory or throw. That is being tracked and worked on separately.
This adds a new TraceItem::EventType union member - TraceEventInfo. This allows event info for invocations of a trace or tail worker to show up when tailing it (i.e. attaching a tail to a tail worker). TraceEventInfo only contains an array "traces" of objects with a single "scriptName", i.e. the script that the script _you're_ tracing was tracing. There's hypothetically more that could be included on these items, but any sort of recursive could ballon the size of these events or even get into circular references, so it's kept simple for now.
921020a
to
d3cc155
Compare
When tailing a tail worker, messages previously had a null event property. Following cloudflare/workerd#1248, these events have a valid event, specifying which scripts produced events that caused your tail worker to run. As part of rolling this out, we're filtering out tail events in the internal tail infrastructure, so we control when these new messages are forward to tail sessions, and can merge this freely. One idiosyncracy to note, however, is that tail workers always report an "OK" status, even if they run out of memory or throw. That is being tracked and worked on separately.
This adds a new TraceItem::EventType union member - TraceEventInfo. This allows event info for invocations of a trace or tail worker to show up when tailing it (i.e. attaching a tail to a tail worker).
TraceEventInfo only contains an array "traces" of objects with a single "scriptName", i.e. the script that the script you're tracing was tracing. There's hypothetically more that could be included on these items, but any sort of recursive could ballon the size of these events or even get into circular references, so it's kept simple for now.