Trace propagation across the Eimer mesh
Right now, once a message crosses a transport boundary (renderer → preload → main → worker, etc.), there's no way to tell that two operations on different nodes belong to the same logical request. If someone reports "the counter update was slow," I have no way to answer whether that was IPC overhead, a slow RPC handler, or something further down the mesh — every process just logs in isolation.
I'd like Eimer to support propagating a trace across the mesh, so a single user action can be followed end-to-end no matter how many processes it touches.
What I want
- Propagate a trace ID + span ID with every message. Something W3C Trace Context / Perfetto-compatible (
traceId + spanId, with a parent/child relationship between spans) so it's not a bespoke format — ideally something that could later be bridged into an existing tracing backend without translation.
- Let application code use this without Eimer's involvement. If my own code on one node starts a trace and calls
callRpc/publish, whatever's on the other end should be able to read that same trace context and open its own spans in it, purely as a courtesy Eimer provides — Eimer itself doesn't need to know or care what's inside.
- Optionally let Eimer trace itself, per call. Sometimes I don't just want to see my own spans — I want to see where time actually went inside Eimer's own plumbing (the RPC round trip, message relaying between processes, etc.), for a specific call, without turning it on globally and drowning in noise for every message.
- Be able to collect all of this somewhere. With N processes each producing their own spans, I need some way to get those spans out of each process and reassembled into one picture, without hardcoding one specific destination (console, file, a real tracing backend) into the library.
Constraints
- Must be fully opt-in — a mesh that doesn't use any of this should behave exactly as it does today, at zero cost.
- No breaking changes to existing message/RPC signatures if avoidable.
- Should work across every transport Eimer already supports, not just IPC.
This is a fairly foundational addition, so I'd rather get the core shape right (id format, how a trace attaches to a message, how self-tracing is opted into) before building any actual collectors/exporters on top of it.
Trace propagation across the Eimer mesh
Right now, once a message crosses a transport boundary (renderer → preload → main → worker, etc.), there's no way to tell that two operations on different nodes belong to the same logical request. If someone reports "the counter update was slow," I have no way to answer whether that was IPC overhead, a slow RPC handler, or something further down the mesh — every process just logs in isolation.
I'd like Eimer to support propagating a trace across the mesh, so a single user action can be followed end-to-end no matter how many processes it touches.
What I want
traceId+spanId, with a parent/child relationship between spans) so it's not a bespoke format — ideally something that could later be bridged into an existing tracing backend without translation.callRpc/publish, whatever's on the other end should be able to read that same trace context and open its own spans in it, purely as a courtesy Eimer provides — Eimer itself doesn't need to know or care what's inside.Constraints
This is a fairly foundational addition, so I'd rather get the core shape right (id format, how a trace attaches to a message, how self-tracing is opted into) before building any actual collectors/exporters on top of it.