Error: Call to a member function getAlias() on null

Been looking at this too. We got it using this scenario:

server: node A with alias.
client: sync node A, alias is set.
server: node A remove alias.
client: sync node A, error getAlias on null.

The problem as far as I can see is that there processors who are already saving the processed_entity in their processEntity them selves before the importService calls save on the processed_entity. This causes the pathitem postSave hook to be triggered with a PID that is no longer valid.

Removing the processed_entity->save() calls in the processors seem to be fixing the problem (in our case).
need some more testing to confirm.

Path for the merge request.
It removes the save call in the processor, since the importService saves the entity anyway.
Note; if you also use the layoutbuilder patches, check the processors too and remove the save call there too.

The last submitted patch, 7: 3383789 -7-82.diff, failed testing. View results →
- codesniffer_fixes.patch Interdiff of automated coding standards fixes only.

I'm seeing this too.

Tried the MR, but it doesn't fix the problem.

However, if I enable the Path alias processor on my import configuration, then it works properly.

I think the problem comes from the path field being sort of an entity reference (it refers to a path alias entity) and sort of not, in that the field holds the path value as well, and isn't considered as being a reference field.

In the JSONAPI data for the node, we have this:

      "path": {

            "alias": "/my-alias-one",
            "pid": 1,
            "langcode": "en"

      },

I'm not sure how best to fix this -- I can see several options:

1. Make the path alias processor compulsory, the same way the Entity reference processor is
2. Make the Entity reference processor treat path alias fields as a reference (which would have the same effect, I think, but just a different way of doing it)
3. Have something else skip a path alias field if the path alias processor is not present

I think this is something the maintainers would need to make a decision on, as I'm not sure which direction this module should take.