Skip to content

call setEventInfo() for custom events#175

Merged
dom96 merged 2 commits intocloudflare:mainfrom
edevil:custom_event_info
Nov 17, 2022
Merged

call setEventInfo() for custom events#175
dom96 merged 2 commits intocloudflare:mainfrom
edevil:custom_event_info

Conversation

@edevil
Copy link
Contributor

@edevil edevil commented Nov 16, 2022

Custom events do not currently get a timestamp assigned, instead being logged with an unix epoch value. Create a custom event info, empty for now, so that we can correctly set the timestamp.

Custom events do not currently get a timestamp assigned,
instead being logged with an unix epoch value. Create
a custom event info, empty for now, so that we can
correctly set the timestamp.
@edevil
Copy link
Contributor Author

edevil commented Nov 16, 2022

cc @harrishancock @dom96

Copy link
Contributor

@dom96 dom96 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me. With the caveat that I don't have a lot of experience with this code path, but even if this doesn't work the change seems safe.

@dom96 dom96 merged commit bdbd607 into cloudflare:main Nov 17, 2022
Copy link
Member

@a-robinson a-robinson left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah I don't know if this is what we'll want when we start wanting to provide info specific to a given custom event type, but this looks fine for getting the timestamp populated.


auto& context = incomingRequest->getContext();
KJ_IF_MAYBE(t, incomingRequest->getWorkerTracer()) {
t->setEventInfo(context.now(), Trace::CustomEventInfo());
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this code belongs inside the custom event callback, not here. That way the event can potentially decide what type of info to add. Additionally, you would have avoided the need for #177 as you could have this code execute after incomingRequest->delivered().

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Makes sense. I'll look into it tomorrow.

penalosa pushed a commit to penalosa/workerd that referenced this pull request Nov 18, 2022
* Improve implementation of DOMException (cloudflare#159)

* Implements API for connecting to TCP servers in workers

* Adds TCP sockets sample implementing a Gopher proxy.

* call setEventInfo() for custom events (cloudflare#175)

* call setEventInfo() for custom events

Custom events do not currently get a timestamp assigned,
instead being logged with an unix epoch value. Create
a custom event info, empty for now, so that we can
correctly set the timestamp.

* Update src/workerd/io/trace.h

Co-authored-by: Dominik Picheta <dominikpicheta@googlemail.com>

* fix context.now() when handling a trace

The TraceCustomEventImpl is a custom event
and when handling it the incomingRequests list
is empty, causing getCurrentIncomingRequest() to fail.

A new version of IoContext::now() is introduced for
when we already have an incoming request available.

* Add missing `locked` property to `ReadableStream` define

* Add `CfHostMetadata` type parameter to `Request` override

Allows the `HostMetadata` type parameter on
`IncomingRequestCfProperties` to be specified with `Request`

Co-authored-by: James M Snell <jsnell@cloudflare.com>
Co-authored-by: Dominik Picheta <dominik@cloudflare.com>
Co-authored-by: André Cruz <acruz@cloudflare.com>
Co-authored-by: Dominik Picheta <dominikpicheta@googlemail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants