Details
-
Improvement
-
Resolution: Unresolved
-
Neutral
-
None
-
None
-
None
-
None
Description
Context
I discovered the "issue" while creating integration tests for the new feature "Headless p13n via rest" (see MGNLPN-550), for this scenario:
Personalized endpoint delivers a page variant based on multiple traits country plus cookie.
Expected behaviour
When choosing the audience for a variant, we can add multiple traits. In consequence the assumption is, that the trait resolver takes combinations of traits into consideration.
Example
A page has 4 variants:
- variant-0: trait-country = CH
- variant-1: trait-country = US
- variant-2: trait-cookies=weatherLocation_Basel
- variant-3: trait-country = CH & trait-cookies=weatherLocation_Basel
When requesting the resources with trait-country=CH&trait-cookies=weatherLocality_Basel
I would expect the trait resolver to return variant-3.
Current behaviour
The trait resolver returns the variant with the first trait which matches.
From the given example above, it returns variant-0.
I could change the order of the variants, swapping the positions of current v-0 and v-3 - this then would return new v-0 - as expected. But the order of the variants should not affect the result returned by the trait resolver.
Additional notes
The traits are resolved as explained above not only on the new / upgraded delivery endpoint - but that's how traits are resolved generally so far.
When discussing the problem jsimak told me that rkovarik told him, that this is a "known issue", or in other words, it was a intentional decision to implement as it is now. (Taking trait combinations would require much more resources.)
I report this as discussed with PM of headless team czimmermann