| Previous | Next |
| FSRM_E_AUTO_QUOTA | XACT_S_DEFECT |
XACT_S_ASYNC
Transaction operation started asynchronously
XACT_S_ASYNC is HRESULT 315392 (0x0004D000) from winerror.h. AllStat describes it as “An asynchronous operation was specified; The operation has begun, but its outcome is not known yet.” The severity bit indicates a nonfailure result, but the value carries a specific condition that must not be collapsed into plain S_OK.
In the COM transaction and MSDTC protocol, this result means that an asynchronous operation was specified; The operation has begun, but its outcome is not known yet. Treat it as a distinct branch whose postcondition must be proven before subsequent operations begin.
Where the status is encountered
- ITransaction commit or abort processing; log the exact method and object state instead of interpreting the constant outside that contract.
- Resource-manager enlistment and coordinated outcomes; log the exact method and object state instead of interpreting the constant outside that contract.
- Transaction event-sink notification passes; log the exact method and object state instead of interpreting the constant outside that contract.
Because it is informational, a language binding may expose it as success and hide the symbolic distinction. Keep the original HRESULT available until the code-specific branch has run.
What must be true before accepting it
Verify that the caller waits for the transaction manager’s terminal decision and retains every object required for completion. The caller should make the acceptance test for it explicit in code and telemetry.
Inspect the current generation of every affected object before deciding what happens next.
Evidence and telemetry
- preserve transaction unit of work.
- preserve coordinator and resource managers.
- preserve async completion handle or callback.
- preserve requested retaining flags.
- preserve final commit or abort outcome.
Also record xact_s_async_operation, xact_s_async_state_before, xact_s_async_state_after, UTC time, process and thread identifiers, component version, and a correlation ID. Evidence for it should be reproducible but sanitized, with sensitive buffers represented by length and hash.
Difference from nearby results
It must be distinguished from ordinary S_OK and from failure-severity values in the same API family; its documented state changes control the next action.
Exact handling of it matters because a generic success path cannot express its required next action.
Correct handling and recovery
Track the asynchronous completion mechanism, cancellation policy, and final outcome. Never report commit or abort merely because the request was accepted.
Retry it only when a documented input or state has changed. Distinguish protocol continuation from retrying the entire high-level operation.
Practical scenario
An application submits an asynchronous commit, persists the transaction identifier, and updates business state only after the coordinator reports the final decision.
A regression test should reproduce it, assert the relevant outputs and state, then change only the decisive condition and verify the expected neighboring result or ordinary completion.
References
- Microsoft: COM transaction status codes — official Microsoft material used to interpret it.
- Microsoft: ITransaction::Commit
- Microsoft: ITransaction::Abort
- Microsoft: HRESULT values
Looking for a different code? Search another status or error code.