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
The app should pretty much never do database writes for anonymous users, that's inviting abuse.
Right now, we see semi-regular (but not frequent, at this time) serialization errors for loads of the frontpage, which clearly indicates that it does writes for both anonymous and non-anonymous users.
Please look that over and make sure we only do writes when it's a logged-in user.
Writes only happen on the few days a year when there's an automated change in open commitfests (so ~10 times a year at UTC 00:00). There's only one writer allowed due to the FOR UPDATE. I guess there's a serialization error because there were multiple commitfests with the same enddate (I guess draft and non-draft).
I'd normally do this kind of thing using a cronjob. But I don't have access to the machine that the commitfest app is running on, and so far getting some new permissions has taken multiple months each time. So having cfbot and users trigger the change seemed easier than setting up and testing a cronjob.
If you just create a managed command for it, we can trivially add a cronjob to it. That's a pattern we already have with numerous other cronjobs in the app, so it's not like it's a complete change of how the system was set up...
Activity
JelteF commentedon Mar 2, 2026
Writes only happen on the few days a year when there's an automated change in open commitfests (so ~10 times a year at UTC 00:00). There's only one writer allowed due to the FOR UPDATE. I guess there's a serialization error because there were multiple commitfests with the same enddate (I guess draft and non-draft).
I'd normally do this kind of thing using a cronjob. But I don't have access to the machine that the commitfest app is running on, and so far getting some new permissions has taken multiple months each time. So having cfbot and users trigger the change seemed easier than setting up and testing a cronjob.
mhagander commentedon Mar 2, 2026
If you just create a managed command for it, we can trivially add a cronjob to it. That's a pattern we already have with numerous other cronjobs in the app, so it's not like it's a complete change of how the system was set up...