more precise telemetry types#1765
Conversation
|
|
||
| it("sends data", async () => { | ||
| Telemetry._instance = new Telemetry(noopEffects); | ||
| Telemetry.record({event: "build", step: "start", test: true}); |
There was a problem hiding this comment.
This reminded me why I annotated these as test: true: in case these events ran in CI and made it into our production events, I wanted an easy way to filter them out. Unsure if that's a good enough reason to keep it this way or not or simply try to firewall off any chance of them showing up in our actual data.
I did just double check and we have no recorded events with test: true in them.
|
The signal events can come at any time, outside of a known workflow since they're from system callbacks. So, in order to track it correctly, we'd need to set some global state somewhere for that callback to be able to reference. |
|
I would expect errors to be the top-level event type. Oh, and we do always have session ids to correlate what was happening before something like an error or signal occur, within the same session. |
2 participants
This removes the
[key: string]: unknowninTelemetryDatathat was not being explicit about the contents of telemetry events. Furthermore, this adopts an explicit enumeration of event + step as a union type, such that any additional fields of telemetry data are tied to specific events. And this adopts a page loader so that we don’t have to remember to copy-paste the code into the documentation if and when the types change.This raised a few questions: