When existing recursive references the export feature overrides fields on wrong entity

Created on 26 April 2023, over 1 year ago
Updated 8 November 2023, about 1 year ago

Problem/Motivation

DISCLAIMER: This bug was really hard to find and will be even harder to explain without sharing confidential data. I'll do my best.

I'm running version 3.1.10. I checked the release notes from 3.1.10 to 3.1.15 (the latest version at the moment of writing) and none of the fixes seem to be related to that.
I'll try to replicate this again using the latest version just in case.

Exporting an entity that relates to multiple other entities from different bundles, and so on ... at some point in the chain that circles back and relates to an entity recursively of the same type as the exported one.
This ends up updating fields in the wrong entity.

Steps to reproduce

On environment A, I export node 2 from content type Z.
On environment B, I import the zip package just exported.
In environment B, node 2 is created but also some node 1 (same content type as node 2) fields are updated with the same values as those fields from node 2.

I found that the problem is not the importer itself, but the exporter.
At some point in the exported YML structure, there is a reference to node 1, and some fields got defined as the same values as node 2.
So when the import runs, it not only creates node 2 but also updates some fields on node 1.
The import does properly what the YML definition says, the problem is how the YML definition was generated.

Not all the fields were updated. Some base fields and custom fields were updated and some base fields and custom fields were not.
For instance, the title was not updated, but a custom text field does.
Other base fields were not updated, but referenced paragraphs do.

I was able to replicate this issue multiple times.
I did another test and edited by hand some values on node 1.
Then imported again the original zip package (generated from node 2).
The updated fields by hand on node 1 were replaced with the same values as before belonging to node 2.

My feeling is that the chain of dependencies behaves recursively at some point in the chain, and somehow, the export generates a wrong structure. However, I can not guarantee that the issue is coming from there.
Maybe this happens even without the recursive situation.

@nginex if you think it is useful anything else to help understand the issue better, please let me know.
I really need help on this, as currently, the Single Content Sync module is not trustable to use in production.

Thank you.

πŸ› Bug report
Status

Postponed: needs info

Version

1.4

Component

Code

Created by

πŸ‡¦πŸ‡·Argentina drupal-son

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

  • Issue created by @drupal-son
  • πŸ‡ΊπŸ‡¦Ukraine nginex

    Thanks for reporting,

    I will try to reproduce the issue this week

  • πŸ‡¦πŸ‡·Argentina drupal-son

    Hi @nginex, any update on this? Were you able to reproduce the issue?

  • πŸ‡¦πŸ‡·Argentina drupal-son

    Hi there. Still no updates on this? Were you able to reproduce?

  • Status changed to Postponed: needs info over 1 year ago
  • πŸ‡ΊπŸ‡¦Ukraine nginex

    Hi @drupal-son,

    Sorry for late response,

    I tried a few times to reproduce the issue with different content structure but without luck.

    If you are still on older version, try to update the module to the latest one (perform drush updb and drush cex afterwards), it's safe to update.

    I need to know exact way of reference between node 1 and node 2, so I can set up it on my local and try to reproduce.

    I did not test with paragraphs, maybe the issue is there

Production build 0.71.5 2024