# Expected Diagnosis: transaction-outcome-after-node-failure

The expected result should converge on the case-specific mechanism below while
keeping conclusions bounded by the collected evidence.

## Expected conclusion

The case is a transaction-semantics question, not a TiDB bug. Definite prewrite rejection can be retried or reported as failure, but an RPC or connection failure may lose the response after TiKV processed a request. If retries cannot determine the final commit state, TiDB can return an undetermined outcome. Clients must use idempotent operations or query business state instead of assuming every returned error means rollback.

## Required evidence chain

- Do not classify this as a database bug solely from region or leader errors.
- Distinguish errors that prove a request was rejected from transport errors where the response may have been lost after processing.
- Explain the Undetermined outcome and why an application error does not always prove rollback.
- Recommend idempotency and explicit business-state verification before retrying side effects.