Only left alone ones in `test/tape/transactions.js` which would just
cause unnecessary conflicts and get cleaned up by separate pull
request #1257 anyway.
Previously throwing an error directly from a transaction callback
resulted in knex reporting that transaction's promise as rejected, and
releasing used connection (back to the connection pool), but not
telling the database to roll back that connection's transaction.
There is no requirement that a promise returned from a transaction callback
be in any way directly related to the passed in transaction object, contrary
to what was being implied by the original comment.
We have a helper to log an error message to the console and exit the process. It looks like the only place we use this helper is when we try and fail to [initialize the driver](5a94bc9b17/src/client.js (L159)).
Unfortunately, when we call `process.exit()` without an exit code, it [exits with a `0` exit code](https://nodejs.org/api/process.html#process_process_exit_code) -- which means success.
This is especially a problem when running tests in a CI environment, as it results in a false positive: tests not only do not pass, but they probably didn't even run.
- improved related comments
- renamed `trx._queue` to `trx._previousSibling`
- made code waiting for `trx._previousSibling`, instead of code initializing
that promise, more explicit about waiting for the promise to be either
resolved or rejected, i.e. `settled`/`completed`
- made the code a bit more compact
The only thing each transaction needs to track is its last direct child
transaction. That is then used to prevent each sibling transaction from
starting (i.e. returning its connection) before its predecessor
transaction completed.
Before, if we had parent transaction A, and two nested sibling transactions
inside it: B1 & B2, knex would hang when you asked it to execute any kind of
a database operation in the second child transaction.
Also, it had a bad Promise.settle() call that would break in case the
previous child transaction promise not resolve to an array, which typically
(e.g. when calling trx.commit() on the passed transaction object or
resolving the transaction promise with no value) it would not.
