[MAGNOLIA-7579] Bootstrapping YAML files fails when there are UUID collisions Created: 11/Jul/19  Updated: 25/Nov/20  Resolved: 13/Nov/20

Status: Closed
Project: Magnolia
Component/s: None
Affects Version/s: 5.7.3, 6.1
Fix Version/s: 6.2.5

Type: Bug Priority: Major
Reporter: Viet Nguyen Assignee: Robert Šiška
Resolution: Fixed Votes: 6
Labels: None
Remaining Estimate: 0d
Time Spent: 0.25d
Original Estimate: Not Specified

Issue Links:
causality
is causing PAGES-296 M6 Pages app does not offer to export... Closed
relation
is related to MAGNOLIA-7735 Magnolia won't start if .yaml export ... Closed
Template:
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Bug DoR:
[ ]* Steps to reproduce, expected, and actual results filled
[ ]* Affected version filled
Date of First Response:
Epic Link: LD improvements
Sprint: HL & LD 14, HL & LD 15, HL & LD 16
Story Points: 3

 Description   

BootstrapResourcesTask can be used with YAML files but the underlying code fails when there are UUID collisions even when we specify to replace during collision.

Investigating into the issue shown that info.magnolia.importexport.command.JcrImportCommand.yaml2Jcr(Node, Map<?, ?>) doesn't take ImportUUIDBehavior into account so customers hardly overcome this issue.



 Comments   
Comment by Will Scheidegger [ 01/Apr/20 ]

Hey guys

I was hoping that this would by fixed with 6.1.4 and 6.2. This should not be a big thing I think. But it is a real pain for uns developers. Any chance that this can be moved up in priority? 

Thanks!

Comment by Christopher Zimmermann [ 27/Aug/20 ]

This may actually be the same as https://jira.magnolia-cms.com/browse/MAGNOLIA-7735.

I noticed that the system was logging errors about "UUID already exists: bed25be3-378f-4f80-9140-a7302e045732)" when in fact there were NO previously existing UUIDs. So the logging message was actually incorrect.

Generated at Mon Feb 12 04:25:00 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.