Content Delivery API - Multinode Treepicker always returns the items in the default language

[lauraneto]

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

12.1.1

Bug summary

When requesting an item by path and there is a multinode treepicker property, the items in that property are always returned in the default language, instead of matching the language of the main item.

You can see the issue in a sample demo I built (the requests are done client side, so you can see them by inspecting them in dev tools).
I have two variants of the content, one in pt-PT (https://lauraneto.github.io/Umbraco.Headless.Blazor/pt/blog/blog-1) and another one in en-US (https://lauraneto.github.io/Umbraco.Headless.Blazor/blog/blog-item-1) which are referencing another item (Blog Item 3), which also exists in both languages, but the en-US version is always returned (both the "main" properties like name and the actual properties (expanded)).

Specifics

No response

Steps to reproduce

1. Create a node in multiple languages, where the document type contains a Multinode Treepicker property.
2. Create a second node in the same languages as the previous step.
3. Open the first node and add the second node to the Multinode Treepicker property.
4. Request the first node using the Content Delivery API path endpoint (expanding the multinode treepicker property) in the various languages and check that the items will always be retrieved in the default language, and not the language of the main item, even though it exists.

Expected result / actual result

The content of the referenced item(s) would be returned in the language of the main item.

[github-actions]

Hi there @lauraneto!

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 🤖 🙂

[kjac]

Hi @lauraneto 👋

Thank you for reporting. And thank you for the thorough description and samples. And not least for tinkering with the Delivery API, that's awesome 🚀

I can reproduce this with a standard content picker - but "only" for invariant properties on variant content. Can you confirm that your relatedBlogs is indeed an invariant property?

I suspect you may have uncovered a general caching issue in Umbraco here 🙈

[lauraneto]

Hi @kjac ,

Yes, you are correct, invariant property in variant content indeed!
Oh no! 🫠

[kjac]

Hi there @lauraneto,

Just a quick follow-up. There truly seems to be a caching issue in the Umbraco core, which is barely noticeable when rendering with Razor templates. However, it becomes quite evident in the Delivery API output.

We're going to investigate a fix for this in the coming weeks.

[kjac]

Hi again @lauraneto,

Just a quick follow-up here. The fix for this caching issue didn't make it to 12.2, but I'm definitively expecting it in 12.3 😄

[kjac]

Fixed in #14824

Thank you again for raising this, @lauraneto 👍