When the indexes method is called on the sqlserver adapter, at the end of the method, AutoCommit is forced to true. If you're in a transaction at the time, this causes the adapter to commit the transaction, ending it prematurely. Rails doesn't realize it, though, and the subsequent call to rollback doesn't throw an error.
This shows up particularly clearly with transactional fixtures in testing if you're using the Redhill on Rails Core plugin. At the beginning of the test, the Redhill plugin calls the indexes method, effectively killing the transaction. At the end of the test, teardown rolls back the transaction to restore the test database to a pristine state, but your changes during the test do not rollback because the transaction's already long gone. As a result, subsequent tests have dirty data.
I don't know how frequently the indexes method gets called. I suspect that in production it happens on boot only. However, I could see data integrity issues popping up.
Caching the current AutoCommit at the beginning of the method and restoring it to the cached value at the end appears to alleviate this problem, at least for my machine.
This is related to #8107.
