ronaldbarendse
commented
3 months ago Hi Heather, this is a very frustrating error indeed! The Could not find parent with id... error message can be thrown within Deploy (version 13) when getting the artifact and it has ParentId > 0, but can't find the required entity for:
- Content items (documents/blueprints/media/members): can't find the parent content item;
- Content/media/member types: can't find the parent type (in case of inherited types) or content/media type container (folder), member types don't support containers;
- Data types: can't find the data type container (folder).
The IDs are stored in the umbracoNode table and have a foreign key between the id and parentId columns, so all parent IDs require a row to exist. You can verify this by running the following SQL query against both current/remote environment databases and ensuring no results are returned (this can only happen in the odd case the foreign key doesn't exist though):
SELECT * FROM umbracoNode WHERE parentId NOT IN (SELECT id FROM umbracoNode);The next thing to check is whether the ID that can't be found is actually in the database and what object type is has. Can you share the results of the following query of both current/remote environments (feel free to exclude the text column):
DECLARE @id int = 1084; -- Use the ID from the error message
SELECT * FROM umbracoNode WHERE id = @id OR parentId = @id;If this returns any results, I can check whether the object type is of the expected type. Maybe this is incorrect or Deploy doesn't support the used parent type yet...
When the above doesn't provide any results, the more complex issue might be in the way the CMS publishes/handles notifications. Once a deployment has completed and the database transaction is completed, Deploy publishes the notifications (like DataTypeSavedNotification and ContentTypeSavedNotification) by grouping them per type and only invoking the handlers that implement IDistributedCacheNotificationHandler (see PR https://github.com/umbraco/Umbraco-CMS/pull/14332). This should prevent running user-defined notification handlers, but still ensure the distributed cache (like in-memory cache, NuCache content index, Examine indexes, etc.) keeps everything in-sync.
Sometimes though, these notifications contain entities that were in an intermediate state, like when updating a data type name and then moving it to a different parent. The first DataTypeSavedNotification would contain an outdated parent ID, while the DataTypeMovedNotification would have the correct one.
Deploy also uses these kind of notification handlers to write the UDA files to disk and update the signatures in the database: both actions require creating the artifact 🤔 It could be that one of these actions can't find the parent ID because it's using an outdated entity from a notification, although that seems unlikely, because Deploy doesn't delete items (so even if incorrect, it should still be able to find it) 🤯 A more likely scenario would be that some CMS services haven't cleared their repository cache yet (also done using the notification handlers) and the parent entity was created in the deployment that just completed.
Although we should probably rearchitect the way distributed caches are refreshed in the CMS (e.g. populating a state of required actions based on the notifications and executing them in a specific order, instead of based on individual notifications), I'll see if we can work-around this in Deploy:
- Ensuring CMS distributed cache notification handlers are executed before the Deploy ones (so repository caches are updated first);
- By removing the UDA file/signature when an exceptions occurs, hoping that it will be re-added in a next notification.
hfloyd
I and colleagues have come across this frustrating error message when doing schema updates, and it doesn't provide any decent clues as to WHERE this mysterious id SHOULD be located. Is this a datataype? A content node?
I have noticed this especially on larger operations - such as pushing an entire version-upgraded site to a new Cloud account, or pulling down a site locally. I know with the interconnected nature of doctypes, datatypes, and content nodes (often serving as the "source" of a picker or MNTP), parsing out dependencies can be tricky, but it would be great if these sort of operations could handle things better - at least providing more contextual information in the error messages.
Incidentally, when I came across this today (upgrade of Umbraco 9 to 13, push to new Cloud account) It seems the actual issue blocking the deployment was that the standard "Member" member type had its GUID changed between versions (why? who knows!). I figured I could manage the "collision" by just changing my local one's alias to "MemberOld", and the collision message went away, to be replaced by the "Could not find parent with id ...." message. I was only able to resolve it when I exported the schema from the Cloud site, pulled it down, then exported my local on top of those UDAs (I didn't do a local schema import first because I didn't want to overwrite any of my customizations). When I then re-imported the schema locally, I got a more useful SQL server error about a duplicate GUID value in the property table. Using grepWin, I searched for that GUID across all the local UDA files, and found it was related to the stupid "Member" - though the top-level GUID had been changed, the property GUID had NOT been changed, thus my original "old" member was STILL conflicting with the updated Member. Fortunately for me, Members were not in use in this site, so I just deleted my local "old" Member type entirely, then the schema import was able to complete. When I pushed the deletion of that old Member type UDA to the Cloud site, then it was also able to complete the schema update.