Octopus Package Issue

Hi Team,

We have implemented Octopus with Jenkins and its being used since log. Recently we have saw a strange issue.

For newly created app, The Packages is getting created in Octopus, versions are also getting created and size of the version also we can see.

But when we are clicking on a specific version then we are not able to open it (or any other versions which got created under it). We are getting error “The resource was not found on this server.”

Any idea what can cause this?

We have name of octopus project something like “XXX-XXX-3.0-XX”, will that 3.0 creates any issue?

Please help.

Hi @pritskumar81,

Thanks for reaching out to Octopus and I am sorry to see you’re running into issues.

Would it be possible to get a screenshot of the page you are getting the “The resource was not found on this server” error?
Are you able to create a release at all with this package? If so could I get a screenshot of your Project > Release page as well? For example:

I don’t believe the project name would create any issue.

Looking forward to hearing back.

Regards,
Garrett

Hi Garrett,

I am getting error at following;

  1. Going into Library.
  2. Selecting Package option
  3. Searching for package name
  4. When click on Package name, it list out all the versions created under that Package
  5. While clicking on any version, we are getting that error.

First we just want to download package manually to verify but that is what throwing error.

And yeah we are able to create the release but it’s not pulling out the package contents. Since we are not able to download the package manually so as process is also not able to do the same.

Sorry, Screenshot I won’t be able to share.

Hi @pritskumar81,

It looks like you might have a bad package in the built-in repository.

Would it be possible for you to take a look at Dev Tools (F12 on Chrome and Firefox) and check the Network tab for errors when trying to access the version? This will tell us which API call is happening when the error occurs and should also give us the package that is being ID referenced.
From there, we should be able to utilize the REST API to delete-package.

If you need to respond with anything sensitive please feel free to direct message me instead of posting in the thread! Looking forward to hearing back.

Regards,
Garrett

Hi @pritskumar81,

I just wanted to jump in here quickly as I believe I have hit this same issue (or at least very similar) before and wanted to send a link to the bug report.

In short, I think your suspicion that the 3.0 within the name would be the culprit. When the packageID/version is parsed as regex to split into ID and version components, certain situations like your package ID containing something that looks like a version can cause the split in the incorrect place.

Can you confirm that this “XXX-XXX-3.0-XX” you mentioned is your package ID which you are trying to view in the web portal?

I hope that helps narrow this down, and I look forward to hearing back!

Best regards,

Kenny

Sure, let me debug in that way. Thanks for your inputs.

Thanks Kenneth, we were thinking the same. Today will give a shot without -3.0- but JFYI we have one setup with 3.0 that is working fine. It seems 3.0 with hyphen is creating issue.

Anyways thank you guys for you quick turnaround. Appreciate it!

Hi @pritskumar81,

I appreciate the update! That sounds interesting. Would you happen to have two separate sample package ID strings, where one exhibits this behavior and the other similar one doesn’t, that I can use locally to debug with? Also, which version of Octopus version are you running?

Best regards,

Kenny

Hi @pritskumar81,

I just ran through a test using the literal XXX-XXX-3.0-XX as the package ID and was able to reproduce this The resource was not found on this server. error in the UI. It looks to be the exact same issue as the one linked above as far as I can tell at this point, where it seems to be cutting at the period (.) in the ID. Testing with the slightly modified ID, which was just removing the period (e.g. XXX-XXX-30-XX) and I was able to correctly view the package details in the UI. Would that be an acceptable workaround here?

Best regards,

Kenny