Model trace IDs and event IDs in simulator

[Chriscbr]

I noticed that the traces from the simulator don't match what I initially expected. What I'm going to explain is based on my little knowledge of event sourcing and reading some logging APIs.

A trace is a group of events that are related to each other and can span across many resources and any amount of time. For example, a serverless app that provides an HTTP endpoint that expects an image URL, puts it on a queue, downloads the image, compresses it, and then puts it on a bucket, could generate traces like the following:

1:00am Endpoint (Type=EndpointCalled, TraceId=trace_abc123, EventId=event_1)
1:00am Function (Type=FunctionCalled, TraceId=trace_abc123, EventId=event_2)
1:01am UrlsQueue (Type=MessageAdded, TraceId=trace_abc123, EventId=event_3)
1:05am DownloadAndCompressImageFunction (Type=FunctionCalled, TraceId=trace_abc123, EventId=event_4)
1:10am Bucket (Type=FileAdded, TraceId=trace_abc123, EventId=event_5)

Also, these events usually have another property parentID which references the parent event that generated them. In Event Sourcing, Trace IDs are named Correlation ID and Parent IDs are named Causation IDs. See the following image:

More information on this link: https://blog.arkency.com/correlation-id-and-causation-id-in-evented-systems/.

I'm okay with either naming (traceId and parentId, or correlationId and causationId) but I think we should have those properties. As for the Simulator API, I'd suggest to use the following naming instead (since it's not handling traces per se):

simulator.onEvent({
  callback(event) {},
});

@Chriscbr please, have a look! Let's discuss it if you have time 🙏🏻

_Originally posted by @skyrpex in https://github.com/winglang/wing/issues/918

[Chriscbr]

@skyrpex and I discussed this a little bit offline, what we came up with was something like this:

• every Trace should have an id (always unique), a parentId (reference to another trace that "caused" the current trace), and a traceId (reference to the first trace in the current sequence of correlated events)
• The SDK should create a new trace context when there isn't already one, and use it to group correlated events together through the traceId field
• Discussed the idea of giving traces both start and end timestamps - for now let's skip this, and instead create two traces for situations (representing the start and end of some event) when this is needed

@skyrpex let me know if I missed anything.

[skyrpex]

It looks good to me, except that what you call traces I call it events. So, the SDK logs events which have an ID, a parent ID, and a trace ID. A trace is a group of events (can be in the shape of a tree).

[github-actions[bot]]

Hi,

This issue hasn't seen activity in 60 days. Therefore, we are marking this issue as stale for now. It will be closed after 7 days. Feel free to re-open this issue when there's an update or relevant information to be added. Thanks!

[github-actions[bot]]

Hi,

This issue hasn't seen activity in 60 days. Therefore, we are marking this issue as stale for now. It will be closed after 7 days. Feel free to re-open this issue when there's an update or relevant information to be added. Thanks!