You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Sep 2, 2021. It is now read-only.
Something I've been thinking about for a while is that we need to be careful about data integrity with API calls that are susceptible to time of check to time of use errors. There are a few ways to address this depending on the situation. An article appeared on Hacker News today (PostgreSQL anti-patterns: read-modify-write cycles) that covers this problem and the potential solutions (and luckily for us, using PostgreSQL for its examples.) A while back I also opened an issue for transaction isolation support in Diesel that will help us with this. This isn't an issue that can be fixed with a PR, per se, so let's just use this as a meta-issue for tracking TOCTTOU errors we find in Ruma's code, and as a reminder to think about this when implementing database logic.
The text was updated successfully, but these errors were encountered:
Something I've been thinking about for a while is that we need to be careful about data integrity with API calls that are susceptible to time of check to time of use errors. There are a few ways to address this depending on the situation. An article appeared on Hacker News today (PostgreSQL anti-patterns: read-modify-write cycles) that covers this problem and the potential solutions (and luckily for us, using PostgreSQL for its examples.) A while back I also opened an issue for transaction isolation support in Diesel that will help us with this. This isn't an issue that can be fixed with a PR, per se, so let's just use this as a meta-issue for tracking TOCTTOU errors we find in Ruma's code, and as a reminder to think about this when implementing database logic.
The text was updated successfully, but these errors were encountered: