-
Notifications
You must be signed in to change notification settings - Fork 370
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: always rollback #638
fix: always rollback #638
Conversation
Are you still up for the changes? 🧐 If you need any help, let us know! I'll convert this to a draft in the meanwhile. When it's ready for review again, please remove the draft indicator! 👀 |
Yes yes. I was just a bit busy with other things. |
All good. I think I am known by now as one of the slowest maintainers in open source 😓 |
Fixes ory#637.
What? No way. You are one of best maintainers I have seen around. Regularly checking in, always giving great feedback, pushing PRs through and not leaving them stick around. |
You made my day, thank you :) |
Re-running conformity tests that hung up |
BTW, those tests are failing also in |
ping @aeneasr |
Ah yes it fails because the refresh PR has not yet been merged. I'd like for the OIDC conformity siute to pass first so that we can confirm that the rollback has no unintended effects :) |
Which other PR? |
i merged a workaround, let's see if we're green! |
Related Issue or Design Document
Fixes #637.
Checklist
and signed the CLA.
introduces a new feature.
vulnerability. If this pull request addresses a security vulnerability, I
confirm that I got green light (please contact
security@ory.sh) from the maintainers to push
the changes.
works.
appropriate).
Further comments
There is not much change necessary to get this fixed. See the diff.
There is one logical change I have done: before rollback was not called if commit failed, now I made it that it is called if commit fails. It is generally safe to call rollback outside of a transaction in PostgreSQL (you only get warning), but if the connection is in error state, then rollback is required. So just to be safe, I think it is better to rollback on any error, including when commit fails (because we might not know what is the reason for failure of that call and in what state is the connection).