How do you troubleshoot transaction aborts in Spanner?

Aborts in Spanner almost always trace back to lock contention between concurrent read-write transactions, so troubleshooting focuses on finding and reducing that contention rather than treating each abort as a bug.

1. Check abort rate and lock-wait metrics in Cloud Monitoring, broken down by table, to identify which rows or key ranges are contended.
2. Look for long-running transactions that hold locks while doing unrelated work, like an external API call, between reads and the final commit - shortening the transaction body usually helps more than anything else.
3. Check for a hot key where many concurrent transactions touch the same row, such as a shared counter, and consider redesigning it (e.g. sharded counters) if so.
4. Confirm retry logic is in place - client libraries generally retry aborted transactions automatically, but custom transaction-handling code must do the same or aborts surface as user-facing errors.
5. Review transaction priority if mixing latency-sensitive OLTP work with background batch jobs, since batch work can be given lower priority to reduce its impact on interactive traffic.

The key mental shift is that occasional aborts are an expected part of Spanner's optimistic concurrency model; the goal of troubleshooting is reducing their rate on hot paths, not eliminating them entirely.