Webhook Data Reaches Heroku, but Bot does not create comment in Slack.
esteban-nyc opened this issue · 12 comments
I have a user in the DB, the webhook data from Jira reaches the Heroku application, however the however, a comment is not generated by the Slack bot.
2018-07-11T16:40:44.236529+00:00 heroku[router]: at=info method=POST path="/comment-created?user_id=esanchez&user_key=esanchez" host=ingage-jira-mention.herokuapp.com request_id=79f90f5d-efc3-49af-97f3-cea48f10764e fwd="50.16.82.124" dyno=web.1 connect=0ms service=23ms status=500 bytes=369 protocol=https
Interesting @esteban-nyc .
Did you perform the steps to subscribe to DM's? If not, message your bot on the slack with the word "signup" and click the link that it provides. The bot will only send messages to users who opt in for the feature.
Nevermind, I see you said that you have a user in the DB... if you look at that user, do they have Jira auth tokens on their object? if not, delete the user and try signing up again. Those steps are outlined in the video here: https://youtu.be/5X4-3rkkffo?t=16m29s
It's a known bug #14
Thank you for the response. Yes, I noticed that part of the video, and was able to work around hanging signup as instructed by deleting the DB entry and signing up again. After that, Jira OAuth successful, DB entry successfully created, and I was presented with Jira authentication screen.
The DB entry includes the correct jiraUserna, jiraToken, and jiraTokenSecret. When I run the test of creating a comment on a Jira issue, I see the webhook in my heroku app logs, but the bot doesn't send me the update in slack.
Perhaps also worth nothing that the bot does send me other messages in Slack, for example when I signup or if I type in settings, so it would seem that auth and connecttions from Heroku to Slack or ok, however the comment_created endpoint is failing for me somewhere.
I wonder now whether the issue might be related to the jiraUsername having the jira syntax of (brackets, tilde, [~esanchez]), whereas the json payload from the webhook just uses "esanchez" ?
Including here the object from the DB. I have removed the token and tokensecret.
{
"_id": {
"$oid": "5b462f4bb3dcf700043bed3d"
},
"slackUsername": "esteban",
"__v": 0,
"jiraToken": "",
"jiraTokenSecret": "",
"jiraUsername": "[~esanchez]"
}
@esteban-nyc hm... this is a headscratcher...
I wonder now whether the issue might be related to the jiraUsername having the jira syntax of (brackets, tilde, [~esanchez]), whereas the json payload from the webhook just uses "esanchez" ?
nah, cuz the function that is looking for usermentions is inspecting the actual comment body, not the query params on the POST. This is because the comment body may contain more than one usermention and if so, we should alert each user that is mentioned.
This brings me to my next question, are you mentioning yourself in the comment? The bot will only send messages to users that are mentioned in the comment. You can mention yourself in a comment by typing "@" then your Jira username. I'm sorry if I'm asking questions with obvious answers, I'm just having a bit of trouble debugging this and I'd like to make 100% sure that I understand the steps to recreate.
Yep, @msolomonTMG . No worries, it is a good question. Yes, I am mentioning myself in the comment. Something unique in our instance worth pointing out is that we use LDAP directory. When jira autopopulates my @mention, it shows my email address. Once complete, it displays Esteban Sanchez in the comment. I do, however, see in the Webhook payload from Jira to Heroku (also mongoDB) that "esanchez" is being passed, not my email.
Agree - this is a head scratcher. I see the 500 error, so I think we're failing at getByJiraUsername().
Perhaps we'll spin up a dev environment and add some additional logging to inspect values for the thisUser or index params.
When jira autopopulates my @mention, it shows my email address.
Very interesting... I would expect user.getByJiraUsername() to fail if it does not find anything that looks like "[~username]" in the comment body.
If the LDAP system puts something different in the comment body to represent a user mention (such as an email address or name), perhaps what we could is:
- Add email addresses or name to user objects on signup
- Update getByJiraUsername() so that we look up users by email, name, or username
I'd be happy to make those changes but before I do, I just want to know what exactly your comment bodies look like. Can you share a webhook payload from Jira to Heroku?
Here is what mine look like (I redacted some information): https://gist.github.com/msolomonTMG/e9bccfbcd7eb91adf3537ccb92c89c59#file-commentbody-js-L17
Good idea, @msolomonTMG. Here is what the webhook payload I receive looks like:
https://gist.github.com/esteban-nyc/034a12c0690fa3bb9cfae9a9b011d2c5
I am seeing [~esanchez] in the body.
I see the following in the heroku logs just prior to the payload being logged:
2018-07-13T17:24:16.078027+00:00 heroku[router]: at=info method=POST path="/comment-created?user_id=esanchez&user_key=esanchez" host=ingage-jira-mention.herokuapp.com request_id=7af8a8ea-ee14-4ae5-8ad4-493609bc8b6b fwd="50.16.82.124" dyno=web.1 connect=1ms service=8ms status=500 bytes=367 protocol=https
I am also noticing my payload does not include the issue key like your example does. I wonder might be a factor?
given that your comment body includes a proper user mention, i think the user.getByJiraUsername function should work properly.
now that we know that the issue object isn't included in the response, I would bet that this line would fail: https://github.com/msolomonTMG/jira-comment-slack-notification/blob/master/slack/index.js#L196
i think we should shift focus to figuring out how to include the issue object in the webhook
Yep. Agree. I will look into this more on our side, and follow up with a status early next week. Thank you. I appreciate the responsiveness and help in narrowing down the issue.
Hi @msolomonTMG
Following up here with some additional findings on my end.
We are running Jira version 7.3.3 (Build #73014)
It appears that around version 7.1, Atlassian updated the webhook payloads for comment events. The default payloads do not include the issue body.
There doesn't appear to be a way to include the issue body with the new Webhook APIs, which means the mention bot implementation may not work for any Jira instances running 7.1 or greater.
Atlassian also introduced variable substitution in the webhook URL. We can now append variables to the webhook URL when creating or updating a webhook. The variables are listed below:
${board.id}
${issue.id}
${issue.key}
${mergedVersion.id}
${modifiedUser.key}
${modifiedUser.name}
${project.id}
${project.key}
${sprint.id}
${version.id}
https://developer.atlassian.com/server/jira/platform/webhooks/
Curious to hear your thoughts on this. Wonder if anyone else running Jira 7.1 or greater has found a good workaround. I will also will keep digging into it and share back if I find anything new. Am also willing to test anything out toward helping to get this bot working on our instance.
Two additional Links with more info on this.
https://jira.atlassian.com/browse/JRACLOUD-68140
https://ecosystem.atlassian.net/browse/ACJIRA-1152
Thank you!
@esteban-nyc great research! apologies for my late response, I was on vacation last week.
I just merged a PR (mentioned above) that should solve the issue where payloads lacking issue data fail to send slack messages.
I tested using the payload from your gist -- looks like we can do without the ${variables} in the webhook URL because the comment.self url contains an issue ID!
I also tested my own payloads to make sure this works retroactively when the issue data exists in the payload
try redeploying to heroku and let me know if this is resolved for you
Hi @msolomonTMG. All good - I hope vacation was great.
Good eye re: the comment.self url containing the issue ID. I just redeployed to Heroku and can confirm the bot is now working as expected on Jira 7.3.3!
Thank you for working with us to add support for the new Jira WebHooks. We are good to go, and I believe this issue can be resolved.
Cheers, and thanks again!