POST Web Request from Issue Created trigger fails

[Liam Cuozzo]

I have two rules, one that triggers when an issue is created and one that triggers when an issue is transitioned. Each trigger then is set up to make a POST request to a server running Python Flask with the issue information that we then do stuff with.

For some reason, the issue created automation always fails making the POST request with a 400 response code, but it doesn't look like the request even makes it to the server.

The issue transition automation always works and the server successfully gets the issue information.

The web request actions on the automation are identical as well. I am not sure what else to do to figure out why one action works and the other doesn't.

[Stefan Salzl]

Hi @Liam Cuozzo 

Did you try to add a (or sometimes several) re-fetch data action? sometimes it´s kind of a timing problem. 

Especially in the case of create issue it could be that the api call fires too fast/early. This would also explain why it works on the transition trigger (as data is there already).

Could please furthermore post your rule and your webrequest action?

Best
Stefan

[Liam Cuozzo]

Hi Stefan,

I'm not sure what changed, but I just simply deleted the rule and re-created it and had no issues now. Same thing where it was an Issue Created trigger and a web POST action. I think it was probably the timing issue before. But I am not sure why re-creating the issue would've changed it.

I kept everything the same. Same URL, same header, and then tried different request body types and they all worked.

Thanks,

Liam

[Stefan Salzl]

oh I see. Unfortunately that happens sometimes so rules get glitchy after some edits (like deleting/adding several components or so) :-/

Glad to know it´s working now ;)

Could you please either accept any given answer or post your own answer that describes your solution in details and accept this one? This marks the question as solved and makes it easier for other people to find solutions in the future.

Best
Stefan

[David Pezet]

Do you happen to use the "Hidden" option to hide any headers with credentials in the Web Request? If these actions are copied or modified it seems that it silently requires you to re-add that information (likely a security thing to keep from people reusing stored credentials for other actions).

Also instead of using two separate automations, you might consider using the Field Changed trigger set to Status (which includes Create), unless you also need to catch transitions that loopback on themselves. 

[Liam Cuozzo]

I did not use the Hidden option. I only have 1 header specified to do a somewhat basic auth check. 

Ideally, I would like to be able to differentiate between create and transition, but I have not checked out this other type of trigger. And the transitions should be able to be moved from any state to any other state and trigger this web request.

[David Pezet]

Are you sending Custom Data in the Web Request? I don't recall all the circumstances but some fields might not quite exist yet during the "Create" function, like the Teams field I think is one case, or fields set by a post function. You could end up with some bad JSON that your server hangs up on. If that is the case you can use a default smart value to pass instead  like {{customfield_1234|null}} or something. You might try adding an action to Add Log Event before the Web Request, and copy paste your Custom Data to capture what it looks like on the Jira side.  

[David Pezet]

or check the value first,

{{#if(exists(customfield_1234}}"field":"{{customfield_1234}}"{{/}}

[Liam Cuozzo]

I just choose Issue data (Jira Format) for the request body because I'm still in a development stage and would just log the whole request as I wanted to see what Jira would send for the issue. Like I said in the first post, it doesn't look like the request even hits the server for the Issue Created trigger. 

But thanks for the suggestion of using custom data, I'll have to try that out.

[David Pezet]

Unfortunately I don't have any experience with the Issue Data option. You might create another automation that uses the Incoming Webhook trigger to send the original automations Issue Data to see if there are any format issues that your server might not appreciate or if something is hanging it up before it even gets to the destination?