I am working with a XP Scaled installation of 10.4 in Sitecore Managed Cloud. Recently we had an issue raised where users noticed a delay when publishing content. Whenever we checked, it seemed to have worked. As our site is headless (next.js ISR), there is a bit of a delay anyway between publishing and the target page updating, but it seemed excessively slow.

Upon testing the issue myself, I found an exactly 2-minute delay between successful publish from CM instance, to the content appearing in the CD instance. In our case, I used the layout service as the source-of-truth for whether it was ‘in’ the CD or not — adding a new page and timing how long until the layout service returned the page rather than notfound.

I checked the logs – no errors. I checked the resources – no issues. I checked the event queue, publish queue tables in the database, and they weren’t huge. Nothing pointed to any issues. Until I found the cause. The following code had been introduced while installing the latest cumulative hotfix – at the time 10.4.2 rev 014047 PRE:

<!--  DELAYED EVENT QUEUE ENABLED
      Checks if Delayed Event Queue Worker is Enabled
      Default value: false
-->
<setting name="EventQueue.DelayedEventQueue.Enabled" value="true" role:require="ContentDelivery" />
<!--  DELAY TIME
      Sets the delay time in seconds for the delayed event queue.
      Default value: 120
-->
<setting name="EventQueue.DelayedEventQueue.DelayTime" value="120" role:require="ContentDelivery" />

The hotfix installation steps simply say to add this setting – “As part of the fix for PDXP-702 ‘Caches can be populated with outdated values when replication is configured’, perform the following steps: Add the following setting to Sitecore configuration on Content Delivery servers:” followed by the config above (we dutifully added the role:require=”ContentDelivery”)

The notes fail to describe the scenario when this should be enabled, or the impact of enabling it, although in hindsight this is fairly obvious – a two minute publishing delay. Following a support ticket, I am informed that the setting is only for when SQL replication is used on a web database – to give database replication time to complete before CD processes remote events and clears or rebuilds caches against data that might still be lagging. Makes sense.

In the 10.5 release notes, PDXP-702 is indeed described as “Caches are no longer populated with outdated values when SQL replication is configured.”. Hopefully 10.5 won’t have the issue on a default install because the default value will be “false” as it is in the comment provided.

I expect to see the recommendation appear in a future KB or doc page, to enable the DelayedEventQueue if you see issues with changes not propogating to environments which are connected to a SQL replica, which is perhaps quite an edge case. In the meantime, since a search for the setting returned zero results, I’m publishing this article to help my future self and any others who accidently cause the same issue!