feat: add per-field config for corr_id and cau_id column types

[yordis]

Allow correlation_id_type and causation_id_type to be configured independently as "uuid" (default) or "text", so applications can use arbitrary string identifiers instead of being forced to use UUIDs.

I confirming with @slashdotdash that there was not a strong reason to force everything to be UUID. And people like Greg Young keep giving me solutions that are under the impression that I can use those "concepts" in Sagas where they use it to correlate things, sadly, forcing everything to be a UUID means I lost the structure behind the UUIDv5

[drteeth]

Look really good, in general we can take this. Could you add a bit in the docs explaining the feature and how you would use it? Maybe a bit about why you'd want to use text?

[yordis]

GregYoung — 4/19/25, 7:59 PM
generally for a processor associated to a specific auction this would be done via correlation id ... all the messages for a given auction should have the same correlation id even if they end up in different streams no?

@drteeth suggest like above are given all the time. Some folks aren't aware of the EventStore limitations, so their suggestions always circle around the same thing.

The reason I wanted this is that, in these workflow-style cases, a UUID is often the wrong shape for the correlation itself. If the business concept we are correlating around is “this auction run”, then a value like auction:123 is more accurate and more useful than an opaque generated UUID.

For example, imagine a saga coordinating work across auction-123, bids-123, and payments-123.

All messages in that flow may naturally share the same correlation id, such as auction:123. That gives a stable identifier that is easy to propagate, easy to inspect, and directly tied to the business process being coordinated.

If we force UUIDs there, we usually end up introducing an artificial mapping layer: either we generate a synthetic UUID just for storage, or we add another metadata field carrying the actual business correlation value. In both cases, the real identifier still exists, but now the built-in correlation_id is no longer the thing the workflow actually cares about.

For long-running workflows and saga-style coordination, forcing UUID-only correlation/causation ids can make the model less expressive and push people into duplicating the same concept elsewhere. Keeping uuid as the default still makes sense, but allowing text makes the built-in fields usable for workflows whose natural correlation key is a meaningful string.

---

Also, I forgot to say, looking at a uuid we can not tell anything about it, which is why it can not be used how Greg and others suggested. Not all correlation ids will participate in the saga.

[yordis]

I added some docs

[yordis]

It sounds CI is failing due to flaky test, the last push was documentation changes