Knex.js transaction scope isolation in query builder chains

When a Knex.js transaction callback receives a transient transaction object, query builders constructed from the primary knex instance may not participate in that transaction. This creates a risk of silent data inconsistency where inserts, updates, or selects executed without explicit trx binding operate on a separate connection outside the declared transaction scope.

The binding rule applies uniformly across supported dialects such as PostgreSQL, MySQL, SQLite3, and MSSQL, yet the behavior is not documented as an error condition; Knex emits no warning when a query bypasses the active transaction. Pool retention characteristics further complicate diagnosis in concurrent workloads, as long-lived transactions hold connections until explicit commit or rollback.

• Under what conditions does the query builder retain or lose transaction context when the callback scope expires?
• Does explicit invocation of trx(table) versus base knex(table) guarantee consistent enrollment across dialects?
• How does connection pool configuration interact with implicit transaction abandonment in nested or chained callback patterns?