Making WordPress.org

Opened 9 years ago

Closed 9 years ago

Last modified 9 years ago

#783 closed defect (bug) (fixed)

Some commits miss their ticket

Reported by: johnbillion's profile johnbillion Owned by:
Milestone: Priority: normal
Component: Trac Keywords:
Cc:

Description

A commit with a message which contains Fixes #123 or See #123 means Trac adds a comment to the corresponding ticket. This gets missed occasionally.

Recent examples: [WP30908], [WP30846], [WP30795], [WP30300], [WP30696], [WP30658], [WP30648].

Any idea why this is happening?

Change History (3)

#1 @nacin
9 years ago

  • Resolution set to fixed
  • Status changed from new to closed

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).

#3 @nacin
9 years ago

In 1199:

Trac: Set repository_sync_per_request to empty. see #783.

Note: See TracTickets for help on using tickets.