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)

Thanks again

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!). 

Thanks

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:

Accept:application/javascript, application/json

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.

Thanks Erik. 

I am getting the same result in both Chrome and Firefox. Yes the Accept request header is correct. 

Accept: application/javascript, application/json

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. 

Thanks

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?