Update: I learned today that it is not sufficient to run 1040. You also need to run 1150 - Catalogs and/or 1110 - Customers in order to update the product name. The reason is that in PLP (Product List page) the product name attribute is used (from EcoResTextValue + a bunch of other tables), while the PDP (Product Details Page) is using the product translatio table (EcoResProductTranslation). And the distribution job 1040 do not distribute the table EcoResTextValue. And in such cases the Azure Search is not being updated with 1040.
----------------------------------------
When updating a product name, it can take a very long time before the product name is changed in the eCommerce search result. On the PDP (Product Details Page), the product name is updated quite soon. I don't understand why the update of the search results are so slow (and in many cases never starts returning updated product names). We are using the parameter "ProductSearch.UseAzureSearch", and I expect that this means that some services are used to return the search results.
I have a suspicion that this may be related to caching or update of caching. In the SDK I see there is a file named. cache.settings.json and this file is documented here. In this file there is settings for data on TTL (Time-To-Live) and TTR (Time-To-Refresh) specified in seconds.
For TTL we see that there are 43200 seconds. This is 12 hours !!
"FullProductSearchResult": 43200,
"ProductRefiner": 43200,
For TTR we see that there are 900 seconds. This is 15 minutes !!
"FullProductSearchResult": 900,
"ProductRefiner": 900,
Could the settings in the cache.settings.json be the cause of why there is such a very long delay on when the search ?
Is there a way to "flush" any cache to rebuild the AzureSearch index? (I have tried to use ?cachebypass=get got without any effect)