Create Release Page Selects Wrong Package Version for Latest

So one of our developers ran across an issue today where they noticed that a release had a package version selected that was several thousand builds old.

We have a package uploaded to Octopus called TFSPlugin that’s latest version is 9696-beta. When we click the “Create Release” button the version that shows up in the Latest column for that package is 4141-beta.

When a release is created via the CLI/API in TeamCity, the correct version is retrieved and added to the new release.

When I pull back the latest version using the REST API path /api/packages?nuGetPackageId=TFSPlugin&skip=0&take=1 I get the following:

“ItemType”: “Package”,
“TotalResults”: 225,
“ItemsPerPage”: 1,
“NumberOfPages”: 225,
“LastPageNumber”: 224,
“Items”: [
“Id”: “packages-TFSPlugin.9696-beta”,
“PackageSizeBytes”: 20161451,
“Hash”: “784def5b02f4c7104793a53a43e0dc95edb663b4”,
“NuGetPackageId”: “TFSPlugin”,
“PackageId”: “TFSPlugin”,
“NuGetFeedId”: “feeds-builtin”,
“FeedId”: “feeds-builtin”,
“Title”: “TFSPlugin”,
“Summary”: null,
“Version”: “9696-beta”,
“Description”: null,
“Published”: “2020-10-07T11:26:26.786+00:00”,
“ReleaseNotes”: null,
“FileExtension”: “.zip”,
“PackageVersionBuildInformation”: null,
“Links”: {
“Self”: “/api/Spaces-1/packages/packages-TFSPlugin.9696-beta”,
“AllVersions”: “/api/Spaces-1/packages?nuGetPackageId=TFSPlugin”,
“Feed”: “/api/feeds/feeds-builtin”,
“Raw”: “/api/Spaces-1/packages/packages-TFSPlugin.9696-beta/raw”
“Links”: {
“Self”: “/api/Spaces-1/packages?nuGetPackageId=TFSPlugin&skip=0&take=1”,
“Template”: “/api/Spaces-1/packages{/id}{?nuGetPackageId,filter,latest,skip,take,includeNotes}”,
“Page.All”: “/api/Spaces-1/packages?nuGetPackageId=TFSPlugin&skip=0&take=2147483647”,
“Page.Next”: “/api/Spaces-1/packages?nuGetPackageId=TFSPlugin&skip=1&take=1”,
“Page.Current”: “/api/Spaces-1/packages?nuGetPackageId=TFSPlugin&skip=0&take=1”,
“Page.Last”: “/api/Spaces-1/packages?nuGetPackageId=TFSPlugin&skip=224&take=1”

At the moment we’re telling the developers to be cautions about creating a new release manually, but is there any way to clear a cache or something to get this value to show up correctly?


Hi @Jonathan.Hunter,

First of all welcome to the Octopus forums!

Thanks for reaching out.

What are the commands you’re running within Teamcity to create the release? Are they same as when you run them manually via CLI?

Do you by chance have any channel rules or package versioning rules on the project that could be causing this? Could you please provide some screenshots of the above and we can look into it together?


Hello @jeremy.miller,

My apologies for the delay. Yesterday got fairly busy on us.

The commands issued in TeamCity are the same as I tried via the CLI:

octo create-release --apiKey <api_key>
–server <server_url> --project "<project_name>"
–channel “Default”

We do have channel rules in place but the rule is applied to every step in the project so if was going to cause problems I would think it would cause it across the board and not just this one step’s package selection.

It’s easier to explain than try to screenshot everything. Plus we’re under a security compliance so I don’t think they’d be happy with me screenshotting stuff and passing it around on the

Our packages are uploaded to Octopus with three different suffixes depending on which code branch TeamCity built from. These suffixes are “beta”,“hotfix”, or just no suffix at all. The “beta” suffix relates to all our pre-prod items. The “hotfix” and blank suffixes go towards production level targets. Each of these suffixes correspond to a specific channel in our deployment process.

Each channel has a single version rule that applies to all steps in the process, with no version range, and the pre-release tag set to match the suffix from above. In the Default / non-prod channel it’s set to “beta”, in the Hotfix channel it’s set to “hotfix” and in the Release / production channel it’s set to “^$” Again, in each instance it’s applied to all steps.

Currently we’re only seeing the issue with this one package (out of 137 in the Default channel) when we go to manually create a release. When we do so, this is how it shows up by default:

Channel: Default
Package: TFSPlugin
Latest: 4141-beta
Last: 9697-beta

Channel: Hotfix
Package: TFSPlugin
Latest: 9698-hotfix
Last: 9698-hotfix

Channel: Production
Package: TFSPlugin
Latest: 4143
Last: 9675

The latest versions for this package are:

9698-hotfix on Oct 7, 2020 11:39 AM
9697-beta on Oct 7, 2020 9:54 AM
9675 on Sep 29, 2020 12:31 PM

The info for the package versions showing up is:

4141-beta on Mar 26, 2020 6:02 AM
4143 on Mar 30, 2020 8:04 AM

I’ve went through the Create Release page and selected each channel to create a release on comparing the Latest and Last versions displayed. The Default channel and the Production channel are having problems with just that one package; the rest are fine. The Hotfix channel does not suffer this issue at all.

So yeah. I’m a little curious on this one. Since the automated creation selects the correct version numbers it’s not a huge issue to our process, but our developers do need to be able to create releases and this now requires them to (remember to) manually check the version number and make sure it’s the latest one available, not necessarily just the last one.

Any thoughts?


Hey @Jonathan.Hunter,

Thanks for all the information.

Which version of Octopus Server are you currently running?

Edit: Would you also be able to privately message/email me a HAR capture of you clicking create release on the portal so I can take a look at the API calls?


Version is 2020.4.2. I’ll send you the HAR file in a minute. I may need to scrub it first.

Can’t upload the HAR file. Says it’s too big. Zipped it and still doesn’t let me upload it.

Hey Johnathan,

If you all have a paid license you should be able to upload to our support files.
To do this please do the following:

Log in to
Click your profile in the upper right
Click your organization
Go to the support tab
Then upload any required files.​​​

Please let me know if that works or not.


So we do have a paid license but we don’t have an account. I just emailed it directly to with your name and a link to this thread for context.

Hey Jonathan,

I wanted to let you know I got the file and I’ll take a look at it and let you know if anything jumps out at me.

Please let me know if you have any questions or concerns in the meantime.


Hey Jonathan,

The API call when you create the release is a bit different than the one you’re calling above.

Would you please be able to run

and see if it’s pulling in 4141, or if it still pulls in the latest?

It looks like the difference is its using packageId (not nugetpackageid), and is also filtering on the pre-release tag on top of that.

Please let me know what the outcome is.


So, good news and bad news.

Good news is that the call does bring back the correct version and we’re no longer experiencing the issue.

Bad news is that apparently my manager went in and deleted the offending package version (and any others below a certain date range) so the issue is no longer showing up and cannot be tested against further.

Sorry about that. I greatly appreciate your assistance thus far, and I apologize that we were not able to track down exactly what was happening.

Hey @Jonathan.Hunter,

You’re very welcome, and no worries! You’re right, that’s both good news and bad news. Hopefully it never resurfaces for you again, but if it does we can dig back in and figure it out.

My instinct was there was something in the database for that specific package that’s tripping up the API calls into thinking its the most recent. I imagine that’s the direction we should go if it happens again.

Thanks for the update, and I hope you have a great weekend.


You as well, sir.

My manager did provide some additional information that may or may not help narrow down the bug as apparently this has happened before. It seems that earlier this year they changed the version numbers for this specific package from the 4k range and bumped them up to the 9k range (was a dev request), thus leaving a gap in version numbers. Removing all dangling packages prior to the version jump resolved the issue this time and based on what my manager said it was the route they took the previous time this was encountered as well. I’m not sure if that is helpful or not, but hopefully it narrows down the cause some. Take care.

1 Like

Hey Jonathan,

That’s definitely a weird potential cause to the issue as semver should still pick up the “latest” version. Thanks for the extra information. It’s definitely good to have going forward if we see another customer seeing behavior like this.


This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.