This is not a known issue. And 10k variants are actually in the small spectrum of catalogs, we have seen catalogs with hundreds of trousands entries, or more
How did you programmatically set Condition.Items? What is it value if you load it by debugger?
Thanks Quan. I'm doing it like this...
// campaign = marketing campaign content reference // items = a List<ConentReference> with the variations I am adding var promotion = _contentRepository.GetDefault<BuyQuantityGetItemDiscount>(campaign); promotion.Condition.Items = items; // do some other things like set a description and to/from dates var contentLink = _contentRepository.Save(promotion, EPiServer.DataAccess.SaveAction.Publish); // the save works; then when I read the promo out of the DB like this... var savedPromotion = _contentRepository.Get<PromotionData>(contentLink); // ...and savedPromotion.Condition.Items is exactly what I expect it to be (the same list of items that I set it to above)
I think promotion.Condition.Items and promotion.DiscountTarget.Items might not be holding valid content references of catalog contents. What do they look like - I mean the values in the debugger?
They look okay to me...
Below is a screenshot after creating a new promotion, adding items to it, saving it to Episerver, and then using using IContentRepository.Get<PromotionData> to get a fresh copy of it.
(result.Data is the promotion in question)
Also, I misspoke earlier. Our catalog has over 100k variants (missed a zero!).
What does the commerce content those ContentReferences link to look like?
Reducing those items to only one might help with the debugging.
Initial thought I get is to check the EPiServerErrors.log to see if it can shed any light on the 406.
Also running an sql profiling trace as you reload the promotion in the marketing UI to see if it actually load everything you would expect.
Alright a quick search for 406 makes it clear it is an HTTP issue.
Check the request headers for those contentstructure/ requests.
If they don't contain:
it won't work, it is the application/json that is mandatory i think.
Basically your browser have to inform the server it accepts answers in json otherwise the server will just respond with 406 telling you to get a better browser that supports json.
I am getting the same result in both Chrome and Firefox. Yes the Accept request header is correct.
I'll try reducing the number of items like you suggested above.
Side-note: It does work for Catalogs. That is, some of our promotions apply to a whole catalog, in which case the catalog is the only item in the list. For those promotions, our code does successfully add the catalog, at both the persistence and UI levels.
Maybe a dumb question but you say this is for promotions you create from code, does it work if you added the entries to a promotion in the UI? Do they show up alright after you save and reopen that promotion?
I have a Buy Products for Discount from Other Selection promotion to which I have programmatically added some variants. I know it is working because when I attach the debugger and load the promotion via IContentLoader, I can see that the ContentReferences have been properly saved to the Condition.Items property.
However, when I load the promotion up in the CMS (Commerce > Marketing), the list of items fails to load (screenshot below).
Checking dev tools in the browser, I see two suspicious HTTP 406s that I assume correspond to the missing catalog entry lists.
The only clue I have to offer is that the catalog is huge... some 10k+ entries (mostly variants).
Is this a known issue and is there a workaround? Thanks