Forums

Articles
Create
cancel
Showing results for 
Search instead for 
Did you mean: 

Comments written in pull requests usually result in the wrong event type being created

David Karr
Contributor
June 14, 2018

In an older BitBucket repository, I used the Pull Request Notification plugin to implement a "comment processor", which fires whenever someone writes a comment in a pull request.  This results in a message being sent through our internal instant messaging system, to notify the participants in a review that a comment has been written, with a link to the comment.  This system worked flawlessly for more than a year.

I recently moved to a new project within the same company.  I implemented the exact same mechanism in the BitBucket repo I was using.  I verified all the settings were the same as what I used before, and that the credentials I was using were correct.

What I've found is that this mechanism works for a couple of minutes, about once a week.  I haven't changed the configuration at all since I installed it.

Our internal BitBucket support people turned on debug logging on the server, and what we found was that when the mechanism works, we see an event in the logs that looks like this:

2018-05-25 15:04:33,673 DEBUG [AtlassianEvent::thread-1] xxxxx *BLY4IOx904x10732665x8 1ahxn0w nnn.nnn.nnn.nnn,127.0.0.1 "POST /rest/api/latest/projects/xxxx/repos/xxxxx/pull-requests/715/comments HTTP/1.1" c.a.s.i.n.DefaultNotificationManager Managing notification: PullRequestActivityNotification{user=InternalNormalUser{id=758, username=xxxxx}, timestamp=Fri May 25 15:04:33 EDT 2018, pullRequest=cartms:715, activity=InternalPullRequestCommentActivity{id=6674620, user=InternalNormalUser{id=758, username=xxxxx}, action=COMMENTED, pullRequest.id=715, commentAction=ADDED, comment=InternalComment{id=334665, author=InternalNormalUser{id=758, username=xxxx}, text=This is a test.}}}

However, the vast majority of submitted comments results in an event that looks like this:

2018-05-25 18:34:41,144 DEBUG [AtlassianEvent::thread-10] xxxxx *BLY4IOx1114x10878328x4 jwg1an nnn.nnn.nnn.nnn,127.0.0.1 "POST /rest/api/latest/projects/xxxxx/repos/xxxxx/pull-requests/715/comments HTTP/1.1" c.a.s.i.n.DefaultNotificationManager Managing notification: GeneralCommentAddedNotification{user=InternalNormalUser{id=758, username=xxxxx}, timestamp=Fri May 25 18:34:41 EDT 2018, pullRequest=cartms:715, comment=InternalComment{id=334697, author=InternalNormalUser{id=758, username=xxxxx}, text=Another test.}}

We talked to the vendor of the Pull Request Notification plugin, but this isn't an issue with the plugin.  The core BitBucket machinery is just emitting the wrong event type, most of the time.

Eventually the internal BitBucket support team in my company will submit a technical support ticket to Atlassian, but I don't know when that will happen.  I'm submitting this question in the hope of getting an answer I can feed back to them to jumpstart a fix for this.

1 answer

1 accepted

0 votes
Answer accepted
Caterina Curti
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
June 21, 2018

Hi @David Karr,

I can see that the internal team submitted a support ticket and that the conversation is now happening on the Pull Request Notifier issue tracker.

In particular, this is the link:

https://github.com/tomasbjerre/pull-request-notifier-for-bitbucket/issues/287

 

Cheers,

Caterina - Atlassian

David Karr
Contributor
June 22, 2018

Yes, we were confused by the order of events in the log.  Both cases were emitting the same events.  The root cause of the problem was that I didn't know that comments on merged (or declined) pull requests do not emit events.

Caterina Curti
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
June 22, 2018

Thanks @David Karr for confirming!

Suggest an answer

Log in or Sign up to answer
TAGS
AUG Leaders

Atlassian Community Events