[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