I shipped a transaction bug, so I built a linter
2 days ago
- #static-analysis
- #database-transactions
- #go-programming
- The author shipped a transaction bug where database operations leaked outside transaction boundaries, leading to silent data corruption and race conditions.
- The bug occurred in Go code using the repository pattern with callbacks, where mixing repository scopes (e.g., using s.repo instead of tx) compiled cleanly and passed tests but caused unpredictable failures under load.
- To prevent such bugs, the author built a custom linter using the go/analysis framework, which performs static analysis to detect structural issues like incorrect repository variable usage in transaction callbacks.
- The linter, named transactioncheck, identifies transaction calls, tracks transaction parameters, and recursively analyzes helper functions to ensure all database operations use the transaction-scoped repository.
- Testing was done with analysistest, using // want comments in test files to verify diagnostics, and the linter was integrated into CI to break builds on violations, preventing bugs from reaching production.