| Previous | Next |
| XACT_S_SOMENORETAIN | XACT_S_MADECHANGESCONTENT |
XACT_S_OKINFORM
Transaction sink requests another notification pass
XACT_S_OKINFORM is HRESULT 315396 (0x0004D004) from winerror.h. AllStat describes it as “No changes were made during this call, but the sink wants another chance to look if any other sinks make further changes.” 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 no changes were made during this call, but the sink wants another chance to look if any other sinks make further changes. Ordinary completion must not be inferred from it until the owning component’s state and outputs agree.
What must be true before accepting it
Verify that the sink made no change now but remains eligible to review changes made later by other sinks. Only this contract check establishes that this result is safe for the caller’s next step.
The return of this result can follow observable side effects, so recovery begins with state reconciliation.
Where the status is encountered
- This result can be returned during ITransaction commit or abort processing; log the exact method and object state instead of interpreting the constant outside that contract.
- It can be returned during resource-manager enlistment and coordinated outcomes; log the exact method and object state instead of interpreting the constant outside that contract.
- It can be returned during 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.
Evidence and telemetry
- preserve sink identity and order.
- preserve state snapshot reviewed.
- preserve changes made by later sinks.
- preserve number of inform passes.
- preserve final vote.
Also record xact_s_okinform_operation, xact_s_okinform_state_before, xact_s_okinform_state_after, UTC time, process and thread identifiers, component version, and a correlation ID. For privacy-safe it diagnostics, log metadata and fingerprints instead of confidential source values.
Correct handling and recovery
Keep the sink in the inform sequence and invoke it again only under the transaction protocol when later changes occur. Avoid busy loops when no new state exists.
Retry it only when a documented input or state has changed. Before another call following it, confirm that completed side effects are idempotent or reconciled.
Practical scenario
A validation sink sees no changes, returns this status, and is called again after another sink adjusts a resource. On the second pass it validates the new state.
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.
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.
A nearby HRESULT can change object ownership, output validity, or the permitted next method.
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.