Currently, the sql driver correctly handles resetting session vars when non in transactional mode by providing a cleanup function that wraps the Close() on the connection so that the sql vars are reset on the connection when it is returned to the pool.

However, in transaction mode, no cleanup function is returned, which means that when Commit() or Rollback() is called on the ent.Tx and the connection is returned to the pool, set sql vars persist and leak so that the next user of that pooled connection will still see those sql vars set.

Since many applications (and the guide here suggests: https://entgo.io/docs/migration/row-level-security/) use sql vars to implement RLS, it seems like a footgun that these vars persist. If this is expected, maybe the docs should be updated to indicate that users are responsible for clearing their own sql vars when using transactions?

For transactions this is complicated by the fact that each statement within a transaction may set different sql vars, so it is difficult to track which sql vars to reset without storing every sql var name every set for that transaction. Using SET LOCAL in PostgreSQL offloads that responsibility to PostgreSQL, since that ensure that these will be cleared when the transaction rolls back / commits. However this only works in PostgreSQL

This is one possible fix for this, another might be returning a cleanup function even in transaction context so that sql vars are reset after every statement even in a transaction (results in some extra round-trips to the server but only if sql vars were used). This would have the advantage of working in MySQL