[wp-meta] [Making WordPress.org] #783: Some commits miss their ticket
Making WordPress.org
noreply at wordpress.org
Sun Jan 25 07:31:40 UTC 2015
#783: Some commits miss their ticket
--------------------------+--------------------
Reporter: johnbillion | Owner:
Type: defect | Status: closed
Priority: normal | Component: Trac
Resolution: fixed | Keywords:
--------------------------+--------------------
Changes (by nacin):
* status: new => closed
* resolution: => fixed
Comment:
FIXED !!!
As I always suspected, this was a race condition. There were two things at
play here:
1. On post-commit, we explicitly tell Trac that there's a new commit.
This then posts the comment.
2. On every pageload, Trac checks the repository to see if there's a
commit it doesn't know about it. This would not post a comment.
If that second point beats the post-commit hook to the bunch, then the
comment isn't posted.
Historically, this didn't affect us when we were on Trac 0.11, as it used
an old pseudo-official python script that had its own problems. (We'd
often get stuff posted as 'automattor', the fallback account for when
something went wrong.) When Trac was updated to 0.12, we switched to the
new CommitTicketUpdater (point 1), `repository_sync_per_request` wasn't
added. It wasn't me, but I probably would have missed it too.
Apparently, there's a way to avoid this sync in point 2, by setting
`[trac] repository_sync_per_request` to nothing. I found this when reading
the changelog for Trac 1.0.3 and noticed they added a log warning for when
you use explicit syncing (with the post-commit hook) and don't have
`repository_sync_per_request` set to nothing (it defaults to on for legacy
reasons).
--
Ticket URL: <https://meta.trac.wordpress.org/ticket/783#comment:1>
Making WordPress.org <https://meta.trac.wordpress.org/>
Making WordPress.org
More information about the wp-meta
mailing list