| Previous | Next |
| RPC_S_CALLPENDING | RPC_E_CALL_COMPLETE |
RPC_S_WAITONTIMER
COM is waiting before retrying a call
RPC_S_WAITONTIMER is HRESULT 2147549462 (0x80010116) from winerror.h. The documented description is “OLE is waiting before retrying a request.” The value must be interpreted at OLE message filtering or call control after a rejected or temporarily unavailable request.
The runtime has scheduled a delay and has not yet attempted the next call retry. When this result crosses a language or process boundary, preserve its original numeric form before projections replace it with a broad exception class.
Where the result appears
- This result may surface in OLE message filtering or call control after a rejected or temporarily unavailable request.
Typical causes and interpretation
Common cause categories are: the server asked the caller to retry later; message filtering imposed backoff; the caller is in a modal or busy state. Do not treat the cause list as a checklist of simultaneous failures; use traces and postconditions to select the matching branch.
Key distinction: the runtime has scheduled a delay and has not yet attempted the next call retry.
Correct handling and recovery
The appropriate recovery is to use bounded backoff, keep the STA responsive, cancel when the owner exits, and never turn the timer into an unbounded retry loop. A retry policy needs a bounded attempt count, a state refresh step, and a rule for reconciling work that may already have completed.
Cleanup following it must be generation-aware: do not destroy shared state or outputs owned by an earlier successful operation.
Practical scenario
An automation client receives a busy response from an Office server and waits for the interval chosen by IMessageFilter before retrying.
Coverage should include the exact failure, a corrected success case, and the closest related HRESULT so classification remains stable.
Difference from related HRESULTs
RPC_S_CALLPENDING tracks an in-flight request; it tracks the delay before another attempt.
Tests and telemetry should retain the producing component and operation so future wrappers do not flatten this result into an ambiguous generic exception.
References
Looking for a different code? Search another status or error code.