Discarding nodes tries to discard node from base workspace

[Sebobo]

I'm currently working on a bug for a customer in which they get errors when trying to discard/delete several workspaces.
Neos runs into an exception as nodes from "live" cannot be discarded as it has no base workspace.

So the PublishingService->doDiscardNode collects child nodes of the nodes in the desired workspace, but nodeDataRepository->findByParentAndNodeType returns a mixed list of child nodes from "live" and the target workspace.
See

neos-development-collection/Neos.ContentRepository/Classes/Domain/Service/PublishingService.php

Line 185 in f328dd8

$affectedChildNodeDataInSameWorkspace = $this->nodeDataRepository->findByParentAndNodeType($parentBasePath, null, $node->getWorkspace(), null, false, true);

I currently don't see exactly where findByParentAndNodeType makes sure that only matching nodes are returned.

So IMO the correct solution must be to add the following check before trying to discard the found child nodes:

if (!$affectedChildNodeData->matchesWorkspaceAndDimensions($node->getWorkspace(), $node->getDimensions())) {
    continue;
}

The bug only appears since they upgraded to 8.3, but it might affect 7.3 too and something else had changed.

[dlubitz]

Is there a way to reproduce that behavior?

[Sebobo]

So far I was only able to reproduce this in my customers project but not in the demo yet as it got a bit late yesterday.
Will try to do that today or Monday to fully understand the history of the issue.

[Sebobo]

But it must be something like this:

You have the workspace chain "live" -> "A" -> "B"

You modify a content element in A which has children and also modify one of it's children.
Then you modify the same element in B but not the children.

Then try to discard the changes from B.
Now I expect the changed child from A to appear in the nodes to discard which would discard it, as a base workspace exists.

Still thinking about the Problem with only live + A and the thrown exception that live has no base workspace.

[dlubitz]

Based on the place in the code, it needs to be some moved node, right?

[Sebobo]

Modified should be enough, why do you think moved?
It's definitely not added or removed from what I saw in the database.

[dlubitz]

It's all located in the iteration of the result of findOneByMovedTo .

neos-development-collection/Neos.ContentRepository/Classes/Domain/Service/PublishingService.php

Lines 181 to 197 in cf4077d

	$possibleShadowNodeData = $this->nodeDataRepository->findOneByMovedTo($node->getNodeData());
	if ($possibleShadowNodeData instanceof NodeData) {
	if ($possibleShadowNodeData->getMovedTo() !== null) {
	$parentBasePath = $node->getPath();
	$affectedChildNodeDataInSameWorkspace = $this->nodeDataRepository->findByParentAndNodeType($parentBasePath, null, $node->getWorkspace(), null, false, true);
	foreach ($affectedChildNodeDataInSameWorkspace as $affectedChildNodeData) {
	if (!$affectedChildNodeData->matchesWorkspaceAndDimensions($node->getWorkspace(), $node->getDimensions())) {
	continue;
	}
	/** @var NodeData $affectedChildNodeData */
	$affectedChildNode = $this->nodeFactory->createFromNodeData($affectedChildNodeData, $node->getContext());
	$this->doDiscardNode($affectedChildNode, $alreadyDiscardedNodeIdentifiers);
	}
	}
	$this->nodeDataRepository->remove($possibleShadowNodeData);
	}

[Sebobo]

Ah yes 🤦
Could explain, why it wasn't noticed more often.