Setup

So reproduce this problem you need to cause a serialization failure on commit. On postgres it'll issue a notice telling you that you tried to rollback but no transaction is open.

Versions

• Rust: 1.88
• Diesel: 2.2.0
• Diesel_async: 0.6.1
• Database: Postgres
• Operating System: Linux

Feature Flags

• diesel:
• diesel_async: postgres

Problem Description

Diesel is issuing rollback statement after the transaction is already closed (due to serialization error on commit).
Note that the rollback is indeed necessary if the serialization error came from any other statement other than commit.

What are you trying to accomplish?

I'm trying to use diesel async in a highly async context with lots of concurrent transactions that can fail on serialization isolation level.

What is the expected output?

No rollback is ever issue without an open transaction.

What is the actual output?

Rollback is issue without open transaction because the failed commit already closes the transaction.

Are you seeing any additional errors?

I'm seeing a rust-postgres log notice coming from the database that's telling me I'm doing something wrong.
log: WARNING: there is no transaction in progress

Steps to reproduce

I added a test that intends to show what I'm seeing.
https://github.com/lsunsi/diesel_async/blob/reproduce-rollback-after-commit/tests/transactions.rs#L110

Checklist

• I have already looked over the issue tracker for similar possible closed issues.

• This issue can be reproduced on Rust's stable channel. (Your issue will be
  closed if this is not the case)
• This issue can be reproduced without requiring a third party crate

What I think generated this issue

Coming from this issue #241 the PR that fixed it also added this subtle bug. The reason I think this happened is because the serialization error on commit is different from other serialization errors.

In case this happens on UPDATE for example, the behavior should be to reset the diesel transaction depth while issuing a rollback. In the case of it happening on a COMMIT, the transaction depth should be considered as if the commit had happened (should be reset) but the rollback should not be issued in this case.

cc @lochetti