306ef99bbb
We noticed a couple of spots where transaction tracking events were potentially incorrect. When the connection reconnects with `restore_transactions: true`, we were keeping the original start time for the transaction. In this case it seems more accurate to treat these as separte transactions where the first one finishes as incomplete. Instead of forcing the adapter to tell the transaction manager to suspend (or `detach` or `lost`) the transactions, we can keep that logic encapsulated inside of the Transaction class for when to broadcast a finish event. This means that we won't capture a finish event if you manually call `reconnect!` without `restore_transactions: true`, but that might be worthy of the tradeoff since this is a rare use-case anyway. We also start raising here if the TransactionInstrumenter receives `#start` when already started, or `#finish` when not started. This ensures that we don't quietly end up in any weird states. When marking that a transaction is incomplete, we also want to check that the transaction is materialized to avoid finishing our instrumentation if it hasn't already started. Also added a test to simulate losing a connection without ever materializing a transaction. Co-authored-by: Daniel Colson <composerinteralia@github.com> |
||
|---|---|---|
| .. | ||
| active_record | ||
| arel | ||
| rails/generators | ||
| active_record.rb | ||
| arel.rb | ||