Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix remove duplicate transaction rejection #3324

merged 1 commit into from Jul 2, 2019


None yet
2 participants
Copy link

commented Jul 2, 2019

An attempt to fix third reported issue from #3309.

Basically, if there is initRejectFn it means a transaction is used without a container, it means that _promise is not exposed, it means that if _promise is rejected there will be an unhandled rejection, it means that we should not reject that promise.

initRejectFn will do fine by itself. If an error happens before a transactor resolved (some problem with a connection) then it will reject initPromise which is returned for knex.transaction() so it is exposed and handled easily. If an error happens after a transactor resolved, it means that initPromise is already resolved (with said transactor) and calling initRejectFn will do nothing, but it is ok since only way to get here is from executionPromise rejection and it is exposed too and it will reject only after calls to commit/rollback.

(Ideally though commit and rollback for standalone transactors should reject themselves instead of executionPromise then it will be easier to handle with async/await and no need to expose executionPromise, but that is another issue...)

(Also removed unneeded duplicate call to initRejectFn since _rejecter will call it anyway)


This comment has been minimized.

Copy link
Contributor Author

commented Jul 2, 2019

From logs you can see three unhandled rejection less: before, after.

Two of those (1, 2) removed by this PR match error messages described in the issue. (Third is just timeout stuff, a fluctuation.)

@kibertoad kibertoad merged commit 2513751 into tgriesser:master Jul 2, 2019

2 checks passed

continuous-integration/travis-ci/pr The Travis CI build passed
coverage/coveralls Coverage increased (+0.03%) to 88.096%

This comment has been minimized.

Copy link

commented Jul 2, 2019


Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.