What I noticed:
I started looking into an issue where several synchronization requests unexpectedly entered the Copy Phase after a deployment, even though a Selective Start had not been performed. At first glance, the behaviour appeared inconsistent because some requests entered Copy Phase while others continued directly into Sync Phase. That contrast made the investigation interesting.
The environment involved deploying model changes using an RSM/RSL-based promotion process. The deployment completed successfully. Validation, Commit, Model Update activities, Change Selectors, and request configuration checks all completed without reported issues. However, after the models were brought online, replication did not occur for requests associated with the modified files.
The following messages were observed:
OM:05673 - CONTINUE option not allowed...
The last time this request ran, the copy phase did not complete successfully on all targets.
This request will resynchronize all unprotected tables.
At the same time, other requests followed a different path:
OM:03400 Query returned a copy phase ending timestamp
OM:00644 Copy phase ... will be skipped
OM:00633 Skipping the copy phase, continuing the replication phase
A detailed comparison was performed between the non-production and production RSM files. Model configurations, Change Selectors, DMR settings, and replication setup were reviewed. No discrepancies were identified.
What caught my attention was that identical deployment steps resulted in different startup behaviour across requests.
During the investigation, review of the req_syncpoint table showed that requests entering Copy Phase either had missing records, outdated timestamps, or COPY_CPLT = 0. In contrast, requests that successfully skipped Copy Phase contained valid copy-completion information.
The most important finding was that Model Update itself does not initiate a Copy Phase. A request enters Copy Phase only when the associated information in the req_syncpoint table indicates that a copy is required.
Another key observation was that request IDs can change when an RSL is used to add or regenerate a model. When that happens, existing req_syncpoint information may no longer align with the new request IDs. If the active request ID no longer matches the stored synchronization metadata, the product treats the request as requiring a copy operation.
Once that explanation was applied to the observed behaviour, the results became much easier to understand. Requests with usable copy-completion information continued directly into Sync Phase. Requests whose metadata no longer aligned with the active request IDs defaulted into Copy Phase.
The behaviour turned out to be deterministic rather than random.
Why this design works:
- Predictability: The Copy Phase decision is based on request state information stored in the req_syncpoint table. When valid copy-completion information exists, replication continues directly into Sync Phase. When that information is missing, invalid, or no longer aligns with the active request ID, a Copy Phase is initiated.
- Reliability: The product avoids assuming a request is fully synchronized when required copy-state information cannot be validated. This ensures synchronization state is evaluated consistently.
- Operational Safety: Defaulting to Copy Phase when synchronization metadata cannot be trusted reduces the risk of continuing replication from an uncertain synchronization state.
What's different
There is one extra step.
In this case, the deployment used RSM/RSL promotion between environments. During the investigation, particular attention was given to request IDs and the associated req_syncpoint information.
No significant platform-specific variation was observed in this case.
Why this matters in production:
This investigation highlighted how a deployment can appear successful while synchronization behaviour changes after the model is brought online. Validation and Commit may complete normally, yet request-level startup decisions can still be influenced by the metadata available at runtime.
A request entering Copy Phase unexpectedly can increase recovery time and complicate deployment validation activities. The investigation showed that post-deployment behaviour may be influenced by synchronization metadata rather than the deployment process itself.
Request IDs that no longer align with existing req_syncpoint table records can result in startup behaviour that differs from what operators expect. Understanding that relationship helps reduce troubleshooting time when requests unexpectedly begin a copy operation after a model update.
If you ever see requests unexpectedly entering Copy Phase after an RSM/RSL deployment, it is not random. It is Connect CDC doing exactly what it should.
What changed for me
I was not sure what had changed during the deployment or Model Update that caused some requests to start from the Copy Phase while others continued directly into Sync Phase.
After following the investigation, I became more focused on the request metadata driving startup decisions rather than the deployment action itself.
I also gained a deeper appreciation for how request IDs and synchronization information are connected.
The outcome increased my confidence in the predictability of the startup logic. Understanding the relationship between request IDs and req_syncpoint table data makes similar investigations much easier to approach.
Takeaway
The issue initially appeared to be caused by the deployment process itself. The investigation revealed a different story. The deciding factor was the synchronization information associated with the active request IDs and how that information influenced Copy Phase evaluation during startup.
Closing community question:
Have you encountered situations where request IDs changed during an RSM/RSL-based deployment and led to unexpected Copy Phase behaviour, and what was the most effective way you validated the associated synchronization state?
------------------------------
Neha Goel
*Precisely Software Inc.
------------------------------