[SOLVED] References are not properly restored when restoring from a backup

[p.schmalenbach]

I have…

• [ ] Checked the logs and have uploaded a log file and provided a link because I found something suspicious there. Please do not post the log file in the topic because very often something important is missing.

I’m submitting a…

• [ ] Regression (a behavior that stopped working in a new release)
• [x] Bug report
• [ ] Performance issue
• [ ] Documentation issue or request

Current behavior

When restoring previously created backups via the Restore Backup function the data shown in the “References” and “Referencing” content tabs is not properly restored.
The corresponding API calls (like the GraphQL referencingSCHEMA_NAMEContents operation) also just return an empty list.
The restored contents however still contain the IDs of the referenced contents and changing anything (like a field value) on the content that references another content fixes the problem.

Expected behavior

Referenced and referencing content is correctly restored when restoring an App via the builtin Restore Backup function.

Minimal reproduction of the problem

1. Create a new App
2. Add a new schema with the following configuration:
   • Name: Address
   • Fields:
     • id (FieldType: String)
3. Add a second schema:
   • Name: Person
   • Fields:
     • addresses (FieldType: References)
4. Add a few Address contents (e.g. with the ids 1, 2, 3)
5. Create a new Person content whose addresses field is populated with references to the previously created addresses
6. Check if the data in the References tab on the person shows up correctly
7. Check if the data in the Referencing tab on the addresses show up correctly
8. Create a backup of the App
9. Restore the previously created backup
10. Check 6 & 7 again in the restored App (The data is now “missing”, changing anything on the person however fixes the problem)

Environment

• [ ] Self hosted with docker
• [ ] Self hosted with IIS
• [ ] Self hosted with other version
• [ ] Cloud version
• [x] Self hosted with kubernetes

Version: 7.7.0

Browser:

• [x] Chrome (desktop)
• [ ] Chrome (Android)
• [ ] Chrome (iOS)
• [ ] Firefox
• [ ] Safari (desktop)
• [ ] Safari (iOS)
• [ ] IE
• [ ] Edge

Others:
The problem already existed in the previous version.

[Sebastian]

Thanks. I think the problem exists forever. The restore process rebuilds contents first but it needs the schema for some part of the content restore. So if we just change the order it should work.

[Sebastian]

Would you be able to provide me your backup? A link via PM would be awesome.

[p.schmalenbach]

I can provide you access to the minimal CMS App i created to recreate the problem (which is essential the CMS App described in the “Minimal reproduction of the problem” section).
Providing you access to our primary CMS App is not as easy as it contains sensitive data.
Would be minimal CMS App enough for you?

[Sebastian]

Just create the backup and send me the download link

[Sebastian]

Fixes as part of docker tag dev-7594