Changed Jira Base Url now getting BadRequest Error with no Message

[steven.maglio]

Hello,

We have an integration between an on-premise Octopus Deploy instance and a cloud Jira instance. Yesterday morning (2020-12-03) we worked with Jira to change our Jira instance name/url.

From: ucsb-sist.atlassian.net
To: ucsb-atlas.atlassian.net

We needed to update a handful of integrations to use the new url. Unfortunately, ever since the change, we have been receiving errors within our Octo/Jira integration.

In the screenshot below, you will be able to see two different error messages.

The first error

Unable to publish data to Jira. Response code: BadRequest, Message: An error occurred while posting deployment info to Jira: Response status code does not indicate success: 500 (Internal Server Error).

This is the error that is returned when the system is using the original url https://ucsb-sist.atlassian.net.

In the middle of this deployment, I switched the url to the new one, which leads to …

The second error

Unable to publish data to Jira. Response code: BadRequest, Message:

This is the error that is returned when the system is using the new url https://ucsb-atlas.atlassian.net.

The difference between the messages kind of makes sense, because the old url probably shouldn’t be responding. However, it’s difficult to troubleshoot the new error because there is no Message associated with it.

Here’s the configuration information from my test machine:

So, why not ask Atlassian/Jira about this?

My first thought was to ask them, and so I went to look at the configuration in Jira. And … the configuration looked almost like it hadn’t been configured. However, it’s been soo long since I looked at this page/screen that I have no point of reference to really compare it to.

To me, the page seems to indicate that if I want to know anything about the configuration, I need to click the Get started button.

When I click the Get started button, it starts to redirect to a new screen, but hangs on the loading spinner while it tries to connect to https://jiraconnectapp.octopus.com/.

If I wait long enough, the connection will time out and I will get a Something's gone wrong error toaster from Jira’s standard error handling.

So, I then followed the Support and issues link from the page with the Get started button, which brought me to these forums. That’s why I’m posting here.

Gut Feeling

My gut feeling is that changing the url with Atlassian/Jira messed up the ConnectApp configuration with Octopus Deploy. So, I’m wondering what might be the right path to take in order to look further into this?

Octopus Installation Info

Octopus Deploy Server On-Premise
Version 2020.4.2

Account Info
This forum is kind of public, so I can supply that info; but maybe in a different communication area.

[dane.falvo]

Hi Steven,

I wonder if you get more information from running the Jira connection tests within Octopus?

Jira issue tracking - Octopus Deploy

Basically, expand the “Jira Connect App Password” section on the configuration page and click on the “Test” button.

At a guess, what I think has happened is the Octopus Deploy - Jira Connect App would have been re-installed to the new Jira endpoint/instance. i.e. it was essentially a new “space” that was created and everything migrated across.

If that’s the case - the Jira Connect App password would’ve changed. The Jira Connect App password cannot be retrieved without reinstalling the Octopus Deploy Jira Connect App again from the atlassian marketplace.

I would suggest that removing the JiraConnect app and reinstalling it would be the way to go.

Jira issue tracking - Octopus Deploy

Let me know how you go.

[steven.maglio]

Thank you for responding soo quickly! I apologize for not seeing this earlier.

I have attempted to un-install and re-install the Octopus Deploy for Jira plugin, however … I’ve been receiving an error message for the last 30 minutes.

When I use the browser developer tools to inspect the packets being sent/received, there is a slightly more detailed error message, but it’s not much help:

The app host returned HTTP response code 400 when we tried to contact it during installation. Please try again later or contact the app vendor.

Would you have any insight on where I might have gone wrong?

[dane.falvo]

Hi Steven,

This issue seems to be all on the atlassian end. Installing the app won’t have anything to do with your octopus solution.

I would be having a look at your Proxy and Firewalls. Try some of the suggestions recommended here: https://confluence.atlassian.com/upm/problems-connecting-to-the-atlassian-marketplace-273875718.html

Let me know how you go.

Regards,

Dane

[steven.maglio]

I have to admit that I’m a little bit confused by this response.

That article seems to be directed towards people that have an on-premise based Atlassian/Jira instance. But, we are using a Cloud based Jira instance; so I would hope that there are no firewall/proxy settings that need to be configured between the Cloud Jira instance and the Atlassian marketplace or the Cloud Jira instance and the Octopus Deploy ConnectApp.

When I read the error message

The app host returned HTTP response code 400 when we tried to contact it during installation. Please try again later or contact the app vendor.

I assumed that it meant the Cloud based Jira instance was having a problem reaching out to the Cloud based Octopus Deploy ConnectApp.

Am I misreading that error message?

[dane.falvo]

Hey Steven,

That article seems to be directed towards people that have an on-premise based Atlassian/Jira instance.

You are correct. During installation of the app, your browser also does a direct call to: “https://marketplace.atlassian.com/rest/2/addons/com.octopus.jiraconnectapp.production”.

If you are behind a corporate firewall you may be able to access “ucsb-atlas.atlassian.net” and its sub-pages however a url that starts with marketplace may be blocked, which I thought may cause issues. However, my explanation definitely wasn’t detailed enough, so my apologies.

I assumed that it meant the Cloud based Jira instance was having a problem reaching out to the Cloud based Octopus Deploy ConnectApp.

I 100% agree with you, it definitely seems to be an issue between cloud based Jira and the atlassian marketplace. I have tested the removal and re-adding of the Octopus app and it’s currently working fine for me.

Going off of your “Gut-Feeling” - have you tried removing your cache and cookies or even just running chrome in incognito mode for the re-installation of the app?

Regards,

Dane

[steven.maglio]

During installation of the app, your browser also does a direct call to:
“https://marketplace.atlassian.com/rest/2/addons/com.octopus.jiraconnectapp.production”.

It looks like my browser is able to follow that link. For the most part, my on-premise workstation has unrestricted outbound access (they do use one of the popular DNS blacklists, but I can’t remember which one, and it wouldn’t affect what we are doing).

have you tried removing your cache and cookies or even just running chrome in incognito mode for the re-installation of the app?

Oh! That’s a great idea! I went the route of incognito mode … but I ran into the same error.

The app host returned HTTP response code 400 when we tried to contact it during installation. Please try again later or contact the app vendor.

So, I tried another browser (that I rarely use), and I cleared all the cookies out of it. Still same error.

So … I’m thinkin’ that I should also open up a ticket with Atlassian to see if they have more detailed log information on the requests that are sending from the Atlassian servers and receiving a 400 from the Octopus ConnectApp. What do you think?

[dane.falvo]

Hey Steven,

I’ll reach out to my extended team - but I feel like this is something that is out of our hands.

So … I’m thinkin’ that I should also open up a ticket with Atlassian to see if they have more detailed log information on the requests that are sending from the Atlassian servers and receiving a 400 from the Octopus ConnectApp.

I think its time to raise it with them. I would guess that one of the first questions they might ask is: is it just the OctopusConnect App or is it all apps from the marketplace that you are unable to install?

I would test installing a different app before getting in touch with them and letting them know the outcome.

Regards,

Dane

[steven.maglio]

Oh wow! You just keep coming with the great ideas!

So, I ran the test and I was able to successfully install Azure Pipelines for Jira. So, it does seem to be specific to Octopus Deploy for Jira.

I’ve also created a ticket with Atlassian Support (JST-619985). I know you won’t have access to that support ticket; but I wanted to add the ticket number in case the two support teams ever decide to connect with each other on this.

[dane.falvo]

Hey Steven,

Great plan!
Let me know as soon as you hear back from them.

Regards,

Dane.

[steven.maglio]

I’ve received a reply back from Atlassian Support. The email was really clear and it seems like it would be helpful to just paste it into this thread verbatim:

---

Russ Gould [Atlassian] commented:

Hi Steven,

I tried to install the Octopus Deploy add-on in your site and ran into the same behavior you describe. I took a look at the Jira application logs and discovered the following errors.

2020-12-09 17:46:32.249 ERROR com.atlassian.plugin.connect.plugin.lifecycle.ConnectAddonInstaller.privacy-safe An exception occurred while installing the plugin [com.octopus.jiraconnectapp.production].

Caused by: com.atlassian.plugin.connect.plugin.lifecycle.LifecycleCallbackHttpCodeException: Error contacting remote application 400:[Bad Request]:

Unfortunately, that isn’t telling us much more than what you were already able to identify via the browser console. Jira is receiving a 400 HTTP response from the Octopus Deploy service during the installation attempt. As the service isn’t returning any additional details in the response in terms of what it doesn’t like about the request Jira is making, it’s hard to say why the installation is failing strictly from a Jira perspective.

Would it be possible to ask the folks at Octopus Deploy to check the logs from their service around the time Jira logged the error above on ucsb-atlas.atlassian.net? Note that the 2020-12-09 17:46:32.249 time stamp is in CST.

Also, a common issue when renaming or migrating Jira Cloud sites is that apps break due to the OAuth client key no longer matching the site URL. Usually, this is just a matter of asking the app developer to clear any existing registrations associated with the old site URL or client key and re-installing. Can you ask the folks at Octopus Deploy to verify if there are any existing registrations with their service related to any of the URLs or client keys listed below. If there are, it would be good to clear those out before the next installation attempt.

• ucsb-sist.atlassian.net
• ucsb-atlas.atlassian.net
• Current client key for ucsb-atlas.atlassian.net: dcfcefa1-a251-3284-9906-853c59e4f591

Let me what you hear back from the folks at Octopus Deploy. I added myself as a watcher on the thread you have going with them so I should be in the loop but let me know on this support case if I can be of any further assistance.

Cheers

[dane.falvo]

Hi Steven,

I have raised this with an internal team and they have now triaged it. They will be attempting to clear oauth details as per the suggestion from atlassian.

It is in the queue at number 6 to be fixed. As far as when this might be completed, I am unable to say, but I will let you know when they action it.

Regards

[steven.maglio]

Thanks!

[dane.falvo]

Hi Steven,

I need to apologise for the last communication. This was an error on my part, attempting to be efficient without fully understanding the operating protocols. Your issue is still yet to be triaged.

I will let you know as soon as there is an update. My sincerest apologies.

Regards,

Dane

[corey.underdown]

Hello @steven.maglio I’ve just gone into the jira connect app and removed your oauth token from the installation queue. Could you please try removing and re-adding the connection from the jira side and let us know how that goes.

Regards,
Corey

[steven.maglio]

Thank you both!

That did the trick, we are back in working shape!

[dane.falvo]

Fantastic news!

Regards,

Dane.