Hi Henrik,

Could you post the code for the list-properties? When you say "when we refresh and there is nothing", what are you refreshing?

public List<string> FeatureCategories { get; set; }

public List<string> Features { get; set; }

The lists are populated by a simple loop where we take features and categories from the Page (PageReferenceCollection) and taking the Id.ToString().

What I meant by "refresh" I simply resfresh the Index Overview and Explorer, just to see if anything has been added.

I can't imagine any scenario in which you would have problem indexing that.

To debug it you could:

* Try changing the name(s) of the properties to something completely different. I'm not sure what that would accomplish. It's just a gut feeling that something may turn up by doing so.

* Inspect what is sent during indexing by using Fiddler. Download and install Fiddler 2 and start it. If you are using IIS you need to change your application pool to run as yourself as Fiddler can only intercept requests made by the same user as the one running Fiddler. If you are using IIS Express it should work out of the box. Look for requests to es-api.episerver.com and inspect what is sent over (choose the JSON view in Fiddler).

* Post more context here - the code that populates the lists etc.

Thank you for some ideas for debugging, I will dig into it and see if I can dig some more data out of this and come back here with a response.

Ok, so I tried changing the names of the properties and that worked great! Everything got into the index with populated lists.

I switched back to the original names to see if the problem persisted and I used fiddler for the request and found this is in the logs 

","error":"MapperParsingException[object mapping [Features] trying to serialize a value with no field associated with it, current value [168028]]"}},{"

Ok, so it seems that it's only with the property named "Features" that the issue persists.

I did no changes to the code itself except for the names of the properties.

Aha! You have run into a known but very rare issue. Find uses conventions based on types in order for you to not have to create mappings (like a schema). When a field with a specific value is indexed it's mapped automatically depending on type and name. For regular properties this works great but for lists it can be slightly more problematic as the convention is only by type. What you have run into here is:

1. At some point you index a list with strings but all of the string values contain only numbers. OR you indexed a list of numbers with the same name.

2. As there's no naming convention for lists the search engine falls back to mapping by type and as the list looks to contain numeric values it maps the field for it as numeric.

3. Later you index the same property again. This time it contains a value that isn't only composed of numbers. As the field has already been mapped as numeric you get the above exception.

When you changed the name of the property another field was mapped and this time around it was mapped correctly as a string array.

The simplest two solutions is either to let the property have a different name or clearing your index as that also clears existing mappings.

Thank you for the response. We've decided to just stick to the name change for now.
And from your description of the issue I am guessing it most be connected that we changed the property Feature from a list<object> to list<string> as we had problems with getting facets to work in the right way. 

Maybe not related to this issue but, we tried switching to a whole other index, started up a fresh one on find and the same issue happened there as well, without us having a prior index? Is there somewhere else that the data might be stored? (Or perhaps I am just forgetful and we did do some other stuff first that might have "broken" the index).

Sounds like a likely cause. In general switching between types for properties isn't a problem as their fieldnames are suffixed with a type identifier. Meaning you can switch between...

string MyProp { get; set; }

and

int MyProp { get; set; }

.. as much as you like without losing values if you decide to switch back. However with lists you can run into a few edge cases, such as indexing a bunch of strings that looks like numbers. 

If you used a new index I think the same edge case may have happend there. Guess we'd need a time machine to know for sure :)