Using a completed NpgsqlTransaction silently causes command to execute without transaction

When assigning an NpgsqlTransaction that has already been committed or rolled back to a NpgsqlCommand, the command executes without exception – but the transaction is silently ignored. This leads to the command being executed outside of any transaction, which is very dangerous and non-obvious.

Repro:

await using var conn = new NpgsqlConnection(...);
await conn.OpenAsync();

var tx = await conn.BeginTransactionAsync();
await tx.RollbackAsync(); // or CommitAsync()

var cmd = conn.CreateCommand();
cmd.Transaction = tx;
cmd.CommandText = "INSERT INTO test_table (value) VALUES ('oops')";
await cmd.ExecuteNonQueryAsync(); // Executes, but silently outside of transaction!

Expected behavior:
Throw an InvalidOperationException if the transaction has already been completed, or
At least log or document this behavior clearly.

Environment:
Npgsql version: 5.0.10
PostgreSQL version: 13.2
.NET version: .net core 6

It is documented on the property itself.

npgsql/src/Npgsql/NpgsqlCommand.cs

Lines 1641 to 1650 in 1b55ebc

    
           /// <summary> 
        
           /// This property is ignored by Npgsql. PostgreSQL only supports a single transaction at a given time on 
        
           /// a given connection, and all commands implicitly run inside the current transaction started via 
        
           /// <see cref="NpgsqlConnection.BeginTransaction()"/> 
        
           /// </summary> 
        
           public new NpgsqlTransaction? Transaction 
        
           { 
        
               get => (NpgsqlTransaction?)DbTransaction; 
        
               set => DbTransaction = value; 
        
           }

While we also can add that to our documentation, I'm not sure anyone will actually read it just for a basic property like that one.

It might be ignored by Npgsql, but the ExecuteNonQueryAsync and the rest of the Exexcute-methods, should raise an exception if the transaction being provided is ignored due to the Connection is null and IsComplete is true.

It seems dangerous to do something even though it's clearly not the desired behavior.

@roji

While I would rather not check that property every time we execute a query, we can probably assert each time that property is assigned. @roji do you think it makes sense?

It might be ignored by Npgsql, but the ExecuteNonQueryAsync and the rest of the Exexcute-methods, should raise an exception if the transaction being provided is ignored due to the Connection is null and IsComplete is true.
It seems dangerous to do something even though it's clearly not the desired behavior.

Well, is it any different if someone assigns a non-finished NpgsqlTransaction (e.g. that belongs to a completely different connection) and it gets ignored as well? At the end of the day we simlpy ignore that property. Having said that...

While I would rather not check that property every time we execute a query, we can probably assert each time that property is assigned.

Yeah, that makes sense to me - a simple InvalidOperationException on assignment sounds reasonable...

Add assert to NpgsqlCommand.Transaction if it's completed (npgsql#6151)

Navigation Menu

Repository navigation

Using a completed NpgsqlTransaction silently causes command to execute without transaction #6149

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

	/// <summary>
	/// This property is ignored by Npgsql. PostgreSQL only supports a single transaction at a given time on
	/// a given connection, and all commands implicitly run inside the current transaction started via
	/// <see cref="NpgsqlConnection.BeginTransaction()"/>
	/// </summary>
	public new NpgsqlTransaction? Transaction
	{
	get => (NpgsqlTransaction?)DbTransaction;
	set => DbTransaction = value;
	}

Using a completed NpgsqlTransaction silently causes command to execute without transaction #6149

Description

Activity

vonzshik commented on Jun 30, 2025

FlushNorris commented on Jun 30, 2025

vonzshik commented on Jun 30, 2025

roji commented on Jun 30, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions