| Previous | Next |
| PEERDIST_ERROR_ALREADY_EXISTS | PEERDIST_ERROR_ALREADY_COMPLETED |
PEERDIST_ERROR_OPERATION_NOTFOUND
Can not cancel the requested operation as it has already been completed.
PEERDIST_ERROR_OPERATION_NOTFOUND is Win32 error 4059 (0xFDB) and belongs to Peer Distribution and BranchCache asynchronous cancellation. The system description identifies the immediate condition but does not identify the caller, object, policy, device, service instance, or transition that produced it.
Interpret this result at the API boundary that returned it. Capture it before logging, cleanup, or another Windows call can replace the thread-local last-error value. Compare the recorded inputs with the documented precondition for Peer Distribution and BranchCache asynchronous cancellation rather than starting with a broad system repair.
Where the result appears
- This result can surface during the asynchronous cancellation stage of a PeerDist publisher or consumer.
- This result can surface during a BranchCache request where the requested operation cannot be cancelled because it is no longer active, usually after completion or prior cancellation.
- It can surface during an API call whose diagnosis depends on record operation token, completion callback time, cancellation time, and owner thread.
- It can surface during a recovery path that must reconcile with the completion path and treat cancellation as too late instead of fabricating a new operation.
Likely causes
- the requested operation cannot be cancelled because it is no longer active, usually after completion or prior cancellation.
- the caller made a stale assumption during asynchronous cancellation.
- the observed PeerDist state no longer matched record operation token, completion callback time, cancellation time, and owner thread.
- the wrapper retried before it could reconcile with the completion path and treat cancellation as too late instead of fabricating a new operation.
Diagnostic sequence
Diagnosis of it starts with the exact request type: read, write, create, transition, validation, cancellation, or administrative action. Identify the object generation and subsystem owner, then decide whether the failure happened before side effects, during a partial transition, or after completion. This ordering matters in Peer Distribution and BranchCache asynchronous cancellation because a blind retry can hide stale state or repeat a non-idempotent change.
- record record operation token, completion callback time, cancellation time, and owner thread.
- record the exact PeerDist function involved in asynchronous cancellation.
- record the object generation used for asynchronous cancellation.
- record PeerDistSvc status while evaluating the requested operation cannot be cancelled because it is no longer active, usually after completion or prior cancellation.
- record origin fallback behavior before attempting to reconcile with the completion path and treat cancellation as too late instead of fabricating a new operation.
Correlate it with the owning component’s operational log, the Windows System log, and any subsystem trace. Telemetry for this Win32 error should preserve native identifiers such as a path or file ID, handle generation, node or peer identity, policy ID, object version, offset and length, or transaction token. Retain decimal 4059, hexadecimal 0xFDB, and the producing API even when a localized message is also shown.
State boundary to prove
The decisive boundary for this Win32 error is whether the requested operation cannot be cancelled because it is no longer active, usually after completion or prior cancellation. Prove or disprove that proposition using record operation token, completion callback time, cancellation time, and owner thread together with the exact PeerDist function involved in asynchronous cancellation. When observations for this Win32 error disagree, preserve both and inspect the transition between them instead of choosing the more convenient value.
A focused validation for this Win32 error should recreate the relevant part of this situation: a timeout thread cancels just after the completion callback removed the token. Serializing token removal resolves the ambiguity. The negative case should keep the responsible condition unchanged and confirm error 4059; the recovery case should change only that condition and verify a successful result without an unrecorded side effect.
Suggested diagnostic fields
For error 4059, keep winerr_4059_api, winerr_4059_object, winerr_4059_state_before, winerr_4059_request, winerr_4059_first_status, winerr_4059_verification. These fields distinguish the initial state, requested transition, first status, and verified recovery result.
Handling, retry, and recovery
reconcile with the completion path and treat cancellation as too late instead of fabricating a new operation A retry is justified only after the recorded state that produced this specific code has changed.
Retry it only after evidence shows a change in Peer Distribution and BranchCache asynchronous cancellation. Initialization, asynchronous completion, recall, or service readiness can justify bounded backoff; malformed metadata, invalid identifiers, policy rejection, unsupported versions, and integrity failures require correction. Before repeating a write or configuration operation after it, query completion state explicitly.
What to log for support and telemetry
- log decimal 4059, hexadecimal
0xFDB, and the producing API. - log the target object and observed Peer Distribution and BranchCache asynchronous cancellation state.
- log caller identity, process and thread IDs, machine or node identity, and UTC time.
- log attempt number, elapsed time, previous result, and any partial side effect.
- retain the first lower-level or component-specific error before Win32 translation.
Difference from nearby codes
ALREADY_COMPLETED rejects another operation on completed state; OPERATION_NOTFOUND is specifically about locating the cancellation target.
Practical example
A timeout thread cancels just after the completion callback removed the token. Serializing token removal resolves the ambiguity.
Developer and administrator guidance
Code that handles it should keep its Win32 domain visible across exceptions, RPC responses, and JSON or REST wrappers. Administrators should verify the subsystem evidence before changing policy, deleting state, forcing failover, or replacing storage. Recovery is demonstrated only when a test observes 4059, changes the responsible condition, and confirms that the same operation succeeds without hidden data loss.
References
- Microsoft: System Error Codes (4000–5999) — reference for error 4059.
- Microsoft: Peer Distribution API — reference for error 4059.
- Microsoft: peerdist.h API reference — reference for error 4059.
- Microsoft: BranchCache — reference for error 4059.
Looking for a different code? Search another status or error code.