Elasticsearch index reset doesn't seems to work with "Index latest version" configuration

[jeanbaptistedalle]

Describe the bug

Elasticsearch index reset doesn't seems to work with "Index latest version" configuration

Orchard Core version

OrchardCore 1.8.3

To Reproduce

• Create a content type that is draftable
• Create an elasticsearch index based on that content type without the "Latest version" configured
• The index is well populated with published content items
• Change the "Index latest version" to include draft
• Rebuild/Reset the index
• The index is empty. But if i modify one of my content item, draft or not, it will appear in the index.

Expected behavior

The index should be populated with draft and published content items with "Index latest version"

[MikeAlhayek]

@jeanbaptistedalle after the Rebuild/Reset the index step, did you give the background task to run. Meaning did you check the index right away or did you wait few mins?

The index is empty. But if i modify one of my content item, draft or not, it will appear in the index.

This is expected since the draft is the latest and is the one that will be indexed.

[jeanbaptistedalle]

Yes I waited few minutes but there is no data in the index. And, when the index is built without the "Index latest version" checked, the indexation is quite instant. And yes, if I update a content item, the item is well duplicated in the index, but that issue force us to update every items after we create an index with "Index latest version" checked to be well populated.

But I took some time to debug, it seems that the ElasticIndexingService put items in allLatest variable the content items with ContentItemVersionId as key but later they are accessed with allLatest.TryGetValue(task.ContentItemId, out var contentItem); and so they can't be found and it may be the cause of the bug.

I looked on the main branch, the service has changed so maybe the bug is solved for future version ? Do you think it can be fix to 1.8.3 or do I have to wait for 2.0 ?

[MikeAlhayek]

First we need to figure out the issue, then determine if we can back port it to 1.8.4 or not.

If you like, try to reproduce the issue using main branch, and see if that is something you can fix

[github-actions]

We triaged this issue and set the milestone according to the priority we think is appropriate (see the docs on how we triage and prioritize issues).

This indicates when the core team may start working on it. However, if you'd like to contribute, we'd warmly welcome you to do that anytime. See our guide on contributions here.