causation-id context attribute

[lfourie]

This is a proposed metadata attribute (from Context Attribute Backlog):

causation-id
Type: String
Description: event-id of event that triggered this event to be created (if any). If not triggered in response to an event, then not present. Enables traceability through systems.
Examples:
Event A generated with unique event-id. Event handler receives event and generates a new event in response, Event B. Event B copies the event-id of Event A into its own causation-id so that the chain of events can be properly correlated.
Constraints:
Optional

[duglin]

@cathyhongzhang is this related to your correlation-id issues/PRs? or if not directly related, can it be solved using the same solution - meaning, we provide a place for people to put this an attribute for this info w/o actually defining the attribute itself.

[cathyhongzhang]

Yes, I think so.

[duglin]

Related to (duplicate of?) #24 and as such copying my comment from there:

Based on our previous discussions, I think we can close this one because it appears that there will be many different ways to do correlation and at this time there doesn't seem to be enough momentary around just one mechanism (or property) to justify adding it to the core spec. We discussed how specific producers can add (via extensions) their own correlation properties to the events though.

I'll add this to the list of possible issues to close for the next call - if you have concerns about this please add a comment.

[duglin]

Agreed to close on 10/4 call - see previous comment for why

[yordis]

@duglin would be possible to have an official extension similar to the OTEL tracing, except that isn't related to OTEL

Attribute Name	Type	Description
correlationid	String	An identifier that groups related events in the same logical flow.
causationid	String	An identifier referencing the event or command that directly caused this event.

Both attributes MUST be strings.

No further constraints are imposed on format (UUID, ULID, etc.)—producers and consumers must agree on conventions.

[duglin]

@yordis I can bring this up on our weekly call to see if #25 (comment) still applies, but given no one has mentioned this topic in a very long time I'm doubtful.

Is there any reason why you can't just define an extension for your own purposes? That's not much different than what you've suggested... consumers/producers agreeing on what to use/look for.

[yordis]

Is there any reason why you can't just define an extension for your own purposes?

That is what I have been doing

but given no one has mentioned this topic in a very long time I'm doubtful.

Never took the time to ask, just did it locally and move on.

The only reason I ask is for alignment, bring the conversation and make sure we all in the same page

[duglin]

The only reason I ask is for alignment, bring the conversation and make sure we all in the same page

yup - I certainly understand that desire. Let's see how the group reacts. Are you able to make our weekly call? Hearing directly from users can sometimes help

[duglin]

Reopening to discuss: #25 (comment)