| Previous | Next |
| RTC_E_TOO_MANY_GROUPS | RTC_E_NO_WATCHER |
RTC_E_NO_BUDDY
What the RTC value marks: RTC_E_NO_BUDDY
This code belongs to enabling presence, maintaining buddies/watchers/groups, and processing server-roamed presence state: the requested buddy object is absent from current presence state. Treating it as a generic RTC failure loses the state needed to choose a safe next action.
For correlation, retain 0x80EE0054 in the RTC interface facility 0xEE together with this result; generic HRESULT text can otherwise hide the protocol family and the exact RTC branch.
Evidence should show that you look up by authoritative URI/ID after refreshing the list and checking pending deletes; the diagnostic distinction is that a buddy can be absent even while a watcher or raw subscription for the same URI exists.
Protocol and object state
| RTC area | presence subscription and contact-list |
|---|---|
| Objects to correlate | presence profile, buddy, watcher, group, ACL, SUBSCRIBE/NOTIFY state, presence document |
| Condition to prove | the requested buddy object is absent from current presence state |
| Safe corrective direction | stop using the stale object or add the buddy through the supported flow |
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.
Evidence that separates the cause
- Code-specific proof: look up by authoritative URI/ID after refreshing the list and checking pending deletes.
- Identity and target: presence profile and account.
- State at production: buddy/watcher URI.
- Timing and ordering: group ID and membership.
A safe diagnostic sequence
- Record it and
0x80EE0054at the first RTC method or event that returns it. - Prove the condition by ensuring the trace can look up by authoritative URI/ID after refreshing the list and checking pending deletes.
- Apply one controlled change: stop using the stale object or add the buddy through the supported flow; then verify the result return value and resulting RTC state.
How to handle the result
The owning RTC component should stop using the stale object or add the buddy through the supported flow; it should also settle or cancel its previous operation before callers begin a replacement.
Example: A UI command uses a cached buddy pointer after another endpoint removed the contact.
Actions that do not address this condition
- Do not overwrite the server list with a stale local snapshot after an uncertain roaming result.
- Do not expose a private buddy list or watcher identity in general logs.
Related RTC results
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_DUPLICATE_WATCHER | the watcher is already present in the watcher/authorization collection |
Technical references
- Client Presence Roaming.
- Microsoft RTC return constants.
- SIP presence event package.
- Watcher information.
Looking for a different code? Search another status or error code.