API v2 returning duplicate entry's

[mhuijser-dc]

Which Umbraco version are you using? (Please write the exact version, example: 10.1.0)

15.2.2

Bug summary

We're encountering an issue with the Umbraco V2 API where a specific call returns multiple headers with the same value. In the CMS, the values are configured correctly, but the data received from the API doesn't match what’s set in the CMS. We suspect this might be related to the blueprints used in Umbraco, but we haven't been able to confirm it yet.

Specifics

Steps to reproduce

Steps to Reproduce

Check CMS Configuration

Open the Umbraco CMS.
Navigate to the section where the headers are configured.
Verify that the expected value (e.g., "Detail page header") appears only once.
Execute the API Call

Make the following API request:

GET https://umbraco.io/umbraco/delivery/api/v2/content?fetch=children:&fields=properties[$all[properties[$all[properties[$all]]]]]&sort=createDate:desc&skip=24&take=12

Use a tool like Postman, cURL, or the browser console to execute the request.

Inspect the Response

Look at the response payload, specifically the headers.
Identify if "Detail page header" appears multiple times in the generic header where it should only appear once.

Compare with CMS Data

Check if the response values match what is configured in the CMS.
If they do not, note the discrepancies.

Investigate Umbraco Blueprints (If Applicable)

If content is created from a Blueprint, verify whether the blueprint contains duplicate header values.
Try creating a new item without using a blueprint and see if the issue persists.

Determine if other headers also have duplicated values or if this is isolated to "Detail page header".
If other headers are affected, the issue might be a general duplication problem in the API.

Expected result / actual result

Expected Behavior:
The "Article page title" value should appear only once in the appropriate header.

Actual Behavior:
The value appears multiple times where it should only appear once.

Potential Causes:
Umbraco Blueprints might be duplicating data.
An issue in the API response processing.
Data corruption or unintended duplication in the CMS.

---

This item has been added to our backlog AB#50330

[github-actions]

Hi there @mhuijser-dc!

Firstly, a big thank you for raising this issue. Every piece of feedback we receive helps us to make Umbraco better.

We really appreciate your patience while we wait for our team to have a look at this but we wanted to let you know that we see this and share with you the plan for what comes next.

• We'll assess whether this issue relates to something that has already been fixed in a later version of the release that it has been raised for.
• If it's a bug, is it related to a release that we are actively supporting or is it related to a release that's in the end-of-life or security-only phase?
• We'll replicate the issue to ensure that the problem is as described.
• We'll decide whether the behavior is an issue or if the behavior is intended.

We wish we could work with everyone directly and assess your issue immediately but we're in the fortunate position of having lots of contributions to work with and only a few humans who are able to do it. We are making progress though and in the meantime, we will keep you in the loop and let you know when we have any questions.

Thanks, from your friendly Umbraco GitHub bot 🤖 🙂

[AndyButland]

Could you give a bit more detail on this step please @mhuijser-dc?

Navigate to the section where the headers are configured.

Sorry if this ends up being me missing something obvious, but I'm not clear what you mean here.

[mhuijser-dc]

Hi @AndyButland,

Sure, if you want all the information umbraco support has also a ticket with a lot of more detail information. Umbraco support number is: #77527.

Our client has the ability to create multiple overview pages containing detail pages. In the detail pages, we have defined a header. What we are observing in the response from the Umbraco API v2 call is that multiple headers from different detail pages contain the same title. The rest of the content is entirely unique except for the header.

Our suspicion, based on a similar issue in another project, is that the blueprint functionality the client is using is affecting the values in the database.

[AndyButland]

Just recording some notes from investigation:

To replicate will likely need access to the customer project - unless you look to try to set up an analogous structure and see if can replicate the issue locally.

The narrowed down test request is:

/umbraco/delivery/api/v2/content?fetch=children:investors/real-estate/nieuws-en-publicaties&fields=properties[title,header[properties[$all[properties[title]]]]]&sort=createDate:desc&skip=18&take=2

This will return two records and you can see when you check against the content in the CMS that the title property is correct, the header > items[0] > title > markup is not.

In this response the markup values of <p><strong>Bouwinvest</strong> heeft grote plannen in groeiend Rotterdam Centrum</p> are not correct according to what we see in the CMS. See also that the block's id of f010df01-9fec-4515-b1ac-b3e766124938 is the same for both items, so it's not just the property value, rather the whole block is incorrect.

Note: the following is stripped to make it a bit clearer what the issue is:

{
    "total": 55,
    "items": [
        {
            "contentType": "publicationDetailPage",
            "name": "Bouwinvest koopt 108 zorgwoningen Houthavenkade Zaandam",
            "id": "a0819bd2-10d6-4c08-bd56-c04e8264704b",
            "properties": {
                "title": "Bouwinvest koopt 108 zorgwoningen Houthavenkade Zaandam",
                "header": {
                    "items": [
                        {
                            "content": {
                                "contentType": "genericHero",
                                "id": "f010df01-9fec-4515-b1ac-b3e766124938",
                                "properties": {
                                    "title": {
                                        "markup": "<p><strong>Bouwinvest</strong> heeft grote plannen in groeiend Rotterdam Centrum</p>",
                                    },
                                }
                            },
                        }
                    ]
                }
            },
        },
        {
            "contentType": "publicationDetailPage",
            "name": "Bouwinvest werkt mee aan framework voor gebouwen om klimaatrisico’s in kaart te brengen",
            "id": "9eb0c3eb-e115-429e-ad1f-2a6a2cc19a84",
            "properties": {
                "title": "Bouwinvest werkt mee aan framework voor gebouwen om klimaatrisico’s in kaart te brengen",
                "header": {
                    "items": [
                        {
                            "content": {
                                "contentType": "genericHero",
                                "id": "f010df01-9fec-4515-b1ac-b3e766124938",
                                "properties": {
                                    "title": {
                                        "markup": "<p><strong>Bouwinvest</strong> heeft grote plannen in groeiend Rotterdam Centrum</p>",
                                    },
                                }
                            },
                        }
                    ]
                }
            },
        }
    ]
}

It only seems to be a problem for later pages too. A skip value of 0 or 2 shows two records that appear correct.

[AndyButland]

Just giving a status update following some debugging on this today. I believe you are correct to suspect the use of blueprints causing the issue here.

What seems to be happening is that the block grid output in the response is being cached at an element level, identified by it's GUID. And as these GUIDs are the same in different content items, once the first is retrieved it's returned from the cache for the other.

Creating content from scratch avoids this problem, as the GUIDs are generated for the property as the block grid is populated.

I've verified this by identifying two records returned in the delivery API response, where we see the second item returning the cached value from the first. Looking up by ID in the database with the following query:

select pd.id,nodeId, n.text, n.uniqueid,textValue
from umbracoPropertyData pd
inner join umbracoContentVersion cv on cv.id = pd.versionId
inner join umbracoDocumentVersion dv on dv.id = cv.id
inner join umbracoNode n on n.id = cv.nodeId
where propertyTypeId = 76
and uniqueid in ('a0819bd2-10d6-4c08-bd56-c04e8264704b','131f9eca-d181-479b-a08f-d812a4cf266d')
and dv.published = 1

We can see the textValue fields contains values like the following:

{"contentData":[{"contentTypeKey":"b15b232d-5a7b-4574-bc1a-baa0e0336507","udi":null,"key":"f010df01-9fec-4515-b1ac-b3e766124938",...
{"contentData":[{"contentTypeKey":"b15b232d-5a7b-4574-bc1a-baa0e0336507","udi":null,"key":"f010df01-9fec-4515-b1ac-b3e766124938",...

I.e. the key is the same.

To verify I manually amended one of these records in the database, replacing each instance of the GUID with a new one. Then cleared the database cache, re-requested the response and confirmed I no longer saw the issue.

---

To resolve it seems we need to ensure that even if created from a blueprint, all block grid - and potentially other instances that contain nested elements - have re-generated keys.

That won't fix the issue you have unfortunately, as the data is already created. You could in theory do what I did across all records, but there are 200 or so, so it would be painful to do manually. Another approach might be to look at using the content service, to load and re-save and publish all content after amending the block grid element's ID.

[AndyButland]

It seems this is an old issue, and one that's been resolved at least for newly created content: #14870

I'll do some further investigation to see if there's been a regression, but could I ask too please if you know when this content was created from the blueprints? I.e. is this a new site on 15, or one that's been upgraded with the content created some time ago? Thanks.

Update: does seem to be a regression, as am seeing this with new content created from blueprints on 15.

[AndyButland]

The issue with the creation of content from blueprints not regenerating the IDs used for the element level properties has been fixed now, in #19054 and due in 15.4.

Unfortunately that's not going to help with retroactively fixing the content that's already partly incorrect due to the duplicated element level IDs, and there's not an easy way to resolve that.

As described above, it is possible by fixing up the database content to ensure unique IDs are used, but that would certainly be fiddly and error-prone.

Another approach is to use Umbraco's services to pass the data through the same logic (notification handlers) that we use to regenerate keys. This could be done programmatically in somewhat the same way the PR is handling it.

Alternatively, if the amount of affected content is limited, you could copy the affected content one by one and then delete the originals, as keys are regenerated for the copies.

I'll close this given the cause of the issue is now resolved.