Error message hiding whitespace in bound variable values

[mike]

Hi,

I’ve been trying to diagnose an issue with “bound” account variables in a web app deployment step and I just wanted to call out that the error message could be improved with a little tweak…

I short, I was getting the following error message when attempting to deploy a web app where I’d “bound” the account name to a project-level variable scoped per environment.

There was a problem with your request.
Couldn't find an account with the Id azureserviceprincipal-spn-myaccount. Perhaps the account has been deleted? Either select another account, or create a new account and select it.
 Once you have corrected these problems you can try again.
 If the problem is related to a variable you will need to update the variables for this release or recreate the release for the changes to take effect.
 If the problem is related to the deployment process you will need to create a new release for the changes to take effect.

After checking everything a few times, I refreshed the browser with Fiddler running and saw this response:

{
  "ErrorMessage": "There was a problem with your request.",
  "Errors": [
    "Couldn't find an account with the Id \nazureserviceprincipal-spn-myaccount. Perhaps the account has been deleted? Either select another account, or create a new account and select it.\r\nOnce you have corrected these problems you can try again.\r\nIf the problem is related to a variable you will need to update the variables for this release or recreate the release for the changes to take effect.\r\nIf the problem is related to the deployment process you will need to create a new release for the changes to take effect."
  ],
  "ParsedHelpLinks": []
}

Note the “\n” at the start of the account name - what I’d managed to do somehow was cut&paste the variable name from another project but included a line break!

Once I looked at it in this light, it was obvious there was a line break in the bound value:

it would be useful if the error message showed the value escaped and quoted - e.g.

Couldn't find an account with the Id "\nazureserviceprincipal-spn-myaccount".

Not a major problem, and one I can avoid by being a bit more careful with my cut and paste keys, but it might stop other people scratching their heads in future…

Cheers,

M

[Mark_Ledwich]

Thanks for the clear explanation. We should ignore whitespace at the start/end when finding the account. Here is an issue to track this https://github.com/OctopusDeploy/Issues/issues/5600

[mike]

Hi Mark,

Thanks for the response.

For my 2 cents, I’d just prefer an error message which shows the literal value of the parameter a bit clearer - e.g. Couldn't find an account with the Id '\nazureserviceprincipal-spn-myaccount'. Personally, I don’t really like it when systems make magic changes to my input (like trimming whitespace) as I have to discover (and then remember) which fields do that and which don’t.

For example, I had a follow up issue with the resource group name where I’d stupidly managed to include a leading space character - I caught that pretty quickly when I tried to deploy, but if you implement your suggestion for accounts I’d have 2 different behaviours to remember, i.e. account names get trimmed but resource groups don’t. That just adds to the cognitive load of using the application.

Also, from a previous ticket, I’m pretty sure that some values in Octopus are whitespace-sensitive - e.g. lifecycle phase names retain their leading whitespace - if you create a lifecycle phase called " DEV", that’s the literal name, so now I have to remember which values are safe to be trimmed and which aren’t as well.

And, just thinking out loud, if I use an Account-type parameter in one of my own step templates, will the parameters now get trimmed correctly when I use the step template in a project, or will I need to trim it myself in my scripts so the behaviour is consistent for the consumer of my temp template?

I think I’d prefer a strict system that tells me it can’t find an account specifically called \nazureserviceprincipal-spn-myaccount rather than one that silently converts it into azureserviceprincipal-spn-myaccount (which still might not exist anyway)!

Finally, if I make the same fumble-fingers mistake in the middle of an bound account parameter - e.g. azureserviceprincipal-spn-\nmyaccount, the error message will still only show me Couldn't find an account with the Id azureserviceprincipal-spn-myaccount. unless you change the error message to escape whitespace, so your fix only solves the case of leading / trailing whitespace.

Apologies for the accidental rant - once I got started I found it hard to stop :-). You guys do great work on the product, which I guess is why I always want to spend time giving detailed feedback about my experiences using it.

Cheers,

M

[Mark_Ledwich]

I appreciate the detail. I’m glad you pushed back on this change - after discussing it we agree. The intention is now to improve the display of error messages so that you can see newlines and other whites-pace characters.