9.0: Correctly set Correlation and Causation IDs #3887
Comments
|
Our current idea, as discussed:
ExampleAuthenticated User "user1"Create Node "home"with tethered node "home/main"
Authenticated User "user2"Create node "service"
Authenticated User "user3"Publishing of "user2" changesjust imagined, this is not really possible – but it's relevant for review workspaces
Authenticated User "user1"Rebasing
Publishing of "user1" changes to "live"
|
Makes the `UserIdProvider` a concept of the core package so that the user id can be determined "lazily". In practice this means that we can use the CR instance for _reading_ already before the authenticated user can be determined. When handling commands, an exception will be thrown if no user can be determined at this point. This also adjusts the event decoration in `\Neos\ContentRepository\Core\ContentRepository::handle()` such that `initiatingUserId` and `initiatingTimestamp` is not overridden once it is set (see #3887)
|
After an issue @ahaeslich had today with lots of If it turns out to be too much work to introduce the complete causation/correlation handling for now, we should at least add some property to the ForkContentStream::create(
$rebasedContentStream,
$baseWorkspace->currentContentStreamId,
sprintf('Rebase workspace "%s" (content stream "%s"), $command->workspaceName->value, $command->contentStreamId->value),
) |
|
Ah this issue also made it to our list of big questions. But i dont really understand what is being discussed here, and it troubles me as this topic is marked critical ^^ |
Don't worry. This is critical for debugging the event log, but at least the last suggestion should be very easy to add and without any breaking changes |
As discussed, I created a separate high-prio issue (#4758) for that part and remove this one from the priority list |
|
Reminder: We should also set some kind of "originalEventId" metadata to events published to other content streams in order to correlate those. This will allow us to detect "merges" rather than new events, i.e. instead of %%{init: { 'logLevel': 'debug', 'theme': 'base', 'gitGraph': {'showBranches': true, 'showCommitLabel':true,'mainBranchName': 'Live', 'parallelCommits': false, 'rotateCommitLabel': true}} }%%
gitGraph LR:
branch "content stream A"
commit id:"Node A created"
commit id:"Node A properties set"
commit id:"content stream A closed"
branch "content stream B"
commit id:"Content A stream forked'"
commit id:"Node A created'"
commit id:"Node A properties set'"
commit id: "content stream B closed"
branch "content stream C"
commit id:"content stream B forked"
commit id:"Node A created''"
commit id:"Node A properties set''"
checkout Live
commit id:"Node A created'''"
commit id:"Node A properties set'''"
checkout "content stream C"
commit id:"Content stream C removed"
checkout "content stream B"
commit id:"content stream B removed"
we could produce sth like %%{init: { 'logLevel': 'debug', 'theme': 'base', 'gitGraph': {'showBranches': true, 'showCommitLabel':true,'mainBranchName': 'Live', 'parallelCommits': false, 'rotateCommitLabel': true}} }%%
gitGraph LR:
checkout Live
commit id:"created"
branch "content stream A"
commit id:"Node A created"
commit id:"Node A properties set"
commit id:"content stream A closed"
branch "content stream B"
commit id:"content stream A forked'"
merge "content stream A"
checkout "content stream B"
commit id: "content stream B closed"
branch "content stream C"
commit id:"content stream B forked"
merge "content stream B"
checkout Live
merge "content stream C"
checkout "content stream C"
commit id:"content stream C removed"
checkout "content stream B"
commit id:"content stream B removed"
|
The refactored publishing V3 opens another now used advantage: For commands with multiple events like workspace publishing, we can now centrally add metadata like a simple correlation id. Note that for 'simple' commands we dont need to do this as `RebaseableCommand::enrichWithCommand` will already group them with a causationId which is what we decided to use for tethered nodes for example. The id never changes for causation ids.
The refactored publishing V3 opens another now used advantage: For commands with multiple events like workspace publishing, we can now centrally add metadata like a simple correlation id. Note that for 'simple' commands we dont need to do this as `RebaseableCommand::enrichWithCommand` will already group them with a causationId which is what we decided to use for tethered nodes for example. The id never changes for causation ids.
|
With #5451 this issues is partly solved as that change introduces debug metadata for the Fork events and sets correlation ids based on the parts of the command name and a random suffix which allows to easily spot a rebase, discard or publish in the event log. |
Causation ID == "Command ID" (we don't store it, just conceptually)
PROBLEMS / concepts:
Intuition:
The text was updated successfully, but these errors were encountered: