[2018.10.5] Release page returns 404 for release with package semver2 version

(Marius Gundersen) #1

I have a package with the version 0.3.0-33+feature.JIRA-123-ImportantWork that automatically created a new release with the same version and octopus deployed it correctly. Everything works correctly, apart from the release page. I can go to the deployment page for a deploy, and I see it in the overview and in the /projects/my-project/releases page, but when I click on one of the releases I get a 404 error message. The url for the release page becomes /app#/projects/my-project/releases/0.3.0-36+feature.JIRA-123-ImportantWork, and I suspect it has something to do with the semver2 part of this version number. The error message is

Unhandled error when communicating with the Octopus Deploy server. The server returned a status of: 404

(Kenneth Bates) #3

Hi Marius,

Thanks for getting in touch! That is definitely strange to get a 404 on this release, as it sounds like you only recently created it. I’ve given this a test in my local instance (2019.4.5) and it works just fine on my end when versioning the release and the package the release uses in this exact way.

I can give it a shot in your specific version to confirm if this may have been related to a since-fixed bug, but can you confirm that this release hasn’t been removed by some retention policy? Do you see this release via the API (OctoURL/api/releases/releases-ID)?

I look forward to hearing back and getting to the bottom of this one!

Best regards,

Kenny

(Marius Gundersen) #4

Thank you for the quick reply. I did try to use the Releases-ID url, as that is also what the links part do the json contains, but it just redirects me to the url with the version, that doesn’t work. I found that it also fails when trying to deploy the release to another environment, with the same 404. I can check if it has something to do with retention policy, but I doubt it since other releases have worked perfectly fine until now. I’ve only recently changed the build and deploy process to use semver2 and have the branch name in the version of the package, that’s why I suspect it has somethingt to do with the name. I’ve started the process of upgrading to a newer version of octopus, but things take time.

(Marius Gundersen) #5

I’ve done some more testing and it seems to be problem when creating any release and having + in the version. So to reproduce it:

  • Create a new release using any package
  • Name the release 0.3.0+test
  • The created release returns a 404 error

I haven’t found any issue in GitHub or any relevant release note indicating that it has been fixed, so I don’t know if it is something that has been fixed between our version and the latest version.

(Kenneth Bates) #6

Hi Marius,

Thanks for following up and providing that additional information. Unfortunately I still haven’t had any luck in reproducing this same strange behavior you’re experiencing. Creating a release versioned in this this way (with a +, as 0.3.0-33+feature.JIRA-123-ImportantWork, etc.), it works as expected in my local 2018.10.5 instance.

Are you able to successfully create the release manually via the UI?

I look forward to hearing back and getting to the bottom of this one!

Best regards,

Kenny

(Marius Gundersen) #7

After a lot of head-scratching and poking around I’ve found that the problem is not in Octopus Deploy, but in IIS, which we use as a reverse-proxy. It seems like IIS doesn’t deal with encoded urls correctly, and so they either end up double encoded or double decoded. There is a new feature called useOriginalURLEncoding that can be used to fix this problem, as explained here: https://blogs.iis.net/iisteam/url-rewrite-v2-1

Thanks for your help, even though the problem wasn’t with Octopus after all :slight_smile:

(Kenneth Bates) #8

Hi Marius,

Thanks for following up and letting me know the cause here! Great to hear it’s all sorted. :slight_smile:

Don’t hesitate to reach out if you have any questions or concerns in the future.

Best regards,

Kenny