Experimental Instrumentation of the cloudflare WebSocketPair API for workers #82
Conversation
| export function setConfig(config: ResolvedTraceConfig, ctx = context.active()) { | ||
| // I could not get the context to work properly, so I'm using a global fallback. | ||
| // I suspect this is because I am not initialising the config properly in the WS instrumentation. | ||
| if (!fallbackConfig) { |
There was a problem hiding this comment.
this is actually a bug in this library and/or with context combined with websockets. I tried instrumenting WS on my own and I get the same thing as here: #14
There was a problem hiding this comment.
Hey I think it's an async local storage issue. Happy to jump on a call and work on this together if you would like
|
Anything needed @evanderkoogh to get this moving? |
|
An extra hour or two a day? :D But seriously.. I currently have a bit more time to work on the library and get it up to speed with some of the latest releases Cloudflare has made over the past year or so. The core-logic-refactor branch has finally landed, which is hopefully going to make it a bit easier to add instrumentation support for things like this. |
|
👋 , curious where is this going and or if there's a plan to get this going/merged |
5 participants
Hey @evanderkoogh,
This instruments websocket message and close handling.
This is a pretty hacky PR and I would appreciate your feedback on how to make it ready to merge :)
The major issue I ran into was making sure setConfig ran before getActiveConfig was called, I didn't manage this in the end so ended up adding a hack into config.ts to make the tracing work. I have probably done something obviously wrong
It adds spanEvents for accept, send, and close such that we can see how the websocket connection is behaving on the server, it currently makes no effort to add a parent span from the client message. From what I can see there would not be a good way to infer the traceparent reliably.