What caught me off guard?
I ran into a Model Update situation recently that seemed like it should have been routine.
We checked the queues. We stopped the requests. Everything looked idle.
Then the Model Update failed.
At first, I assumed I had missed something obvious. Maybe there was still data waiting to be applied. Maybe a request had not stopped cleanly. The more I checked, the less sense the failure made.
The queues looked empty. The requests looked stopped. Yet the update still refused to complete.
The clue was hidden in the process, not the queue?
What finally changed my thinking was realising that Model Update is not simply checking whether queue counts have reached zero.
During a Model Update, CDC performs several coordinated actions. It stops running requests, waits for queues to drain, applies the updated model, disables and re-enables capture where required, and then starts the previously running requests again. If one of those steps does not complete within the configured timeout window, the update can fail.
That was the detail I had overlooked.
I was treating the queue as the entire story. CDC was treating it as just one step in a larger process.
Why is " empty " not always empty?
One detail that stood out when I looked into this further:
Queue cleanup is asynchronous to the actual apply process and may be delayed by several seconds or even minutes. The queue statistics and the underlying processing are not always perfectly synchronised.
That means an environment can appear quiet while CDC is still waiting for part of the Model Update workflow to finish.
There are also three timeout areas that can influence whether Model Update succeeds:
- Queue Draining
- Table Capture
- Stop Requests
If any of those operations take longer than expected, Model Update can fail even when the environment initially appears idle.
Why does this matter during troubleshooting?
What surprised me most was how easily an investigation can become focused on the wrong thing.
When people hear "Model Update failed," the natural response is often to look immediately for stuck rows, growing queues, or a backlog.
Sometimes that is the problem. Sometimes it isn't.
In my case, the lesson was that queue depth alone was not enough to explain what CDC was doing. Looking only at the queue made the behavior seem random. Looking at the entire Model Update sequence made it predictable.
Where to get the full technical details?
If you want to understand how to configure and control the timeout settings involved in Model Update - including the Queue Draining timeout option - the official Connect CDC documentation covers it in detail here:
Takeaway:
A queue that appears empty does not automatically mean Model Update is ready to proceed. CDC is waiting for a sequence of operations to complete, and a failure can occur anywhere along that path.
The next time a Model Update fails, even though everything looks idle, it may be worth asking a different question:
Was CDC still waiting for something that the queue statistics alone could not show?
Have you ever had a Model Update fail even though the queues looked clean, and what ended up being the real cause?
*Precisely Software Inc.