| Previous | Next |
| RTC_E_DUPLICATE_BUDDY | RTC_E_MALFORMED_XML |
RTC_E_DUPLICATE_WATCHER
Operational meaning: RTC_E_DUPLICATE_WATCHER
This HRESULT is emitted for a defined RTC state rather than an unspecified communications problem; that state is the watcher is already present in the watcher/authorization collection.
This result is represented as 0x80EE004B in the RTC interface facility 0xEE; record the symbolic name alongside the unsigned hexadecimal value; a decimal exception alone is poor evidence for RTC protocol diagnosis.
To establish this result, compare watcher URI, subscription dialog, ACL state, and pending events; this matters because watchers are subscribers observing presence, not buddies being observed by the user.
Verification workflow
- Start from
0x80EE004Band this result, then find the method/event pair that first exposed it. - To verify this, compare watcher URI, subscription dialog, ACL state, and pending events.
- Keep the analysis at the right boundary: watchers are subscribers observing presence, not buddies being observed by the user.
- After you update authorization on the existing watcher rather than creating another record, repeat the smallest reproducer rather than restarting the entire application environment.
Protocol and object state
| RTC area | presence subscription and contact-list |
|---|---|
| Condition to prove | the watcher is already present in the watcher/authorization collection |
| Objects to correlate | presence profile, buddy, watcher, group, ACL, SUBSCRIBE/NOTIFY state, presence document |
| Safe corrective direction | update authorization on the existing watcher rather than creating another record |
Presence data is subscription state rather than call state; buddy existence, watcher authorization, and current availability are separate concepts. When presence roaming is enabled, the server can act as the presence agent and becomes authoritative for list and subscription updates.
Signals worth preserving
- Code-specific proof: compare watcher URI, subscription dialog, ACL state, and pending events.
- Correlation key: ACL decision and
NOTIFYversion. - Protocol or object snapshot: presence profile and account.
- Last completed transition: buddy/watcher URI.
- Expected output: group ID and membership.
Recovery and control flow
Resolve it at its producing layer: update authorization on the existing watcher rather than creating another record; after it, a separate UI or watchdog retry must wait until that layer reports a final state.
Example: Two NOTIFY-related callbacks attempt to insert the same watcher.
Actions that do not address this condition
- Do not expose a private buddy list or watcher identity in general logs.
- Do not overwrite the server list with a stale local snapshot after an uncertain roaming result.
Do not confuse it with
RTC_E_PRESENCE_ENABLED | code attempted an enable-only presence transition when presence is already active |
|---|---|
RTC_E_DUPLICATE_BUDDY | the buddy URI is already represented in the active presence list |
RTC_E_INVALID_ACL_LIST | the presence access-control list is structurally or semantically invalid |
Technical references
Looking for a different code? Search another status or error code.
