Setup: We have more than 200 tenants attached to different projects and we are deploying those projects. We don’t maintain them manually, don’t worry
Observed behavior: When I try to view a multi-tenanted release with too many tasks I get an empty screen with error message saying: Unhandled error when communicating with the Octopus Deploy server. The server returned a status of: 400.
Cause: The endpoint GET octopus/api/tasks?take=300&ids=ServerTasks-9239,ServerTasks-9238,ServerTasks-9237… is called when you open a release in Octopus. All of the parameters are populated in the query string and in the case of many tasks the URL easily exceeds any sane limits, resulting in 400 bad request response, because the URL is truncated.
Expected behavior: I should be able to view releases with big amount of tasks associated with them.
Suggested solution: Quick one would be to move the parameters to the body. Before saying that this is a get request - there is nothing in the HTTP standard, which says that GET requests should not have bodies More sustainable one would be to not bother displaying so much data. I won’t be checking all 200+ tasks and I honestly don’t wanna see them in one single view. I leave this one to you
We’ve recently been making changes in this area so it’s possible that work may already be underway or complete in order to fix this. Would you be able to let me know which version of Octopus Server you are running so I can check with the team?
Thanks for keeping in touch! Unfortunately I don’t think it’ll be possible to give you 100% confirmation that it will fix or mitigate this exact issue you’re seeing, but my confident guess is it will at least mitigate it, since we have implemented a number of fixes in this area as Charles mentioned. I can’t seem to pinpoint this to a specific issue, but if it’s not too much trouble, upgrading would certainly be worth a try.
If you’re still this issue after upgrading, or if upgrading isn’t possible, I’d like to have a direct look at your project and reproduce this locally. That can be done with an export of the project. Note if this after your upgrade, you’d get the new export/import projects feature, otherwise you’d need to run octopus.migrator partial-export command.
I look forward to getting to the bottom of this one!
Unfortunately the only thing that changed after update is that GET octopus/api/tasks now returns 404. I still cannot view the releases with too many associated tasks.
I did the export you mentioned, but after going through the files I don’t feel very comfortable sharing this. However, I can do whatever diagnostics you require.
The setup itself is quite simple:
A tenanted database deployment project with single step deploying a DAC package to SQL server;
A bit over 200 tenants, containing information about the 200+ databases which need to be deployed;
All the tenants are associated with the mentioned project;
Create a single release for all tenants;
Try deploying this release (success/failure doesn’t really change anything as it’s all about the tasks created);
After deployment try to view the release and you’ll see the error.
Thank you for following up and clarifying those details! I’m sorry to hear the upgrade didn’t help at all. I’m going to set up an attempt to reproduce this issue locally, and I’ll keep in touch with anything I find.
Please let us know in the meantime if you have any questions or concerns.
