| Previous | Next |
| RTC_E_MALFORMED_XML | RTC_E_ROAMING_FAILED |
RTC_E_ROAMING_OPERATION_INTERRUPTED
What the RTC value marks: RTC_E_ROAMING_OPERATION_INTERRUPTED
When RTC returns this result, the relevant contract is synchronizing profile, buddy, watcher, group, or ACL data with the server while preserving update ordering, and it says that a roaming operation ended without a trustworthy commit outcome.
This result carries 0x80EE004D in the RTC interface facility 0xEE; store the result value at the first RTC callback or method boundary, before retry logic replaces it with a broader timeout or connection message.
Collect enough state to record operation ID, last event, transport loss, local version, and then re-enumerate server state; the result evidence should demonstrate why the server may have applied the mutation even though the client observed interruption.
Protocol and object state
| RTC area | RTC roaming synchronization |
|---|---|
| Objects to correlate | roaming event, server version, local cache, operation instance, list document and completion state |
| Condition to prove | a roaming operation ended without a trustworthy commit outcome |
| Safe corrective direction | reconcile fresh server contents before replaying any change |
An interrupted roaming operation has an uncertain outcome: the server may have committed data even when the client did not receive completion. A failed synchronization must be reconciled with fresh server state before replaying list mutations.
Evidence that separates the cause
Capture the first result before retry, reconnect, profile re-enable, or teardown changes the evidence; associate this result with one RTC object instance and one transaction or media transition.
- Code-specific proof: record operation ID, last event, transport loss, local version, and then re-enumerate server state.
- Identity and target: last acknowledged mutation.
- State at production: fresh enumeration after failure.
- Timing and ordering: roaming data type.
Related RTC results
Use “a roaming operation ended without a trustworthy commit outcome” as the discriminator when comparing the related RTC results below.
RTC_E_ROAMING_FAILED | the server-side roaming transaction completed as a failure |
|---|---|
RTC_E_MALFORMED_XML | RTC received or generated XML that cannot be parsed for the roaming or presence operation |
RTC_E_ROAMING_ENABLED | roaming is already enabled for the selected profile or data type |
A safe diagnostic sequence
- Collect enough evidence to record operation ID, last event, transport loss, local version, and then re-enumerate server state.
- Test the competing explanation explicitly, because the server may have applied the mutation even though the client observed interruption.
- Apply the targeted fix — reconcile fresh server contents before replaying any change — and validate both protocol completion and object cleanup.
How to handle the result
Recovery should be narrow: reconcile fresh server contents before replaying any change; while handling this result, do not let a higher layer simultaneously recreate the same session, registration, listener, or profile.
Distinguish local rejection from an operation that may already have reached the server; use transaction identifiers and final events before replaying any non-idempotent action.
Example: The connection drops after an AddBuddy request is sent but before completion arrives.
Actions that do not address this condition
- Do not blindly replay non-idempotent list changes after a disconnect.
- Do not delete the local cache before preserving versions and pending operations.
Verification after a fix
Keep two tests: one that intentionally produces “a roaming operation ended without a trustworthy commit outcome”, and one that applies the targeted fix; check the callback sequence, 0x80EE004D, final session/profile state, and absence of leaked listeners, dialogs, streams, or registrations.
Technical references
- Client Presence Roaming — authoritative context for this result.
- Microsoft RTC return constants — definitions relevant when reproducing it.
- SIP presence event package — API or protocol rules used to interpret it.
Looking for a different code? Search another status or error code.