Self referencing variable loop

After upgrade from 3.4.14 to 3.5. We could not deploy a project to our development environment. (We use DTAP). We got the following error:
“An attempt to parse the variable symbol “variablename” appears to have resulted in a self referencing loop. Ensure that recursive loops do not exist in the variable values”

This variable was not used in the project that was being deployed. I found the “variablename” in our Library Variable set. But it wasn’t used recursively. The “variablename” was referenced in an other variable as part of the value of a connectionstring.

Then I noticed something. I deployed to our development environment. But the “variablename” did not have a scope for Development. I added a value for the “variablename” for the missing scope Development. I redeployed the package and it deployed successfully. The “variablename” was not new and was untouched for a few months.

First of all the error message is misleading, secondly the variable isn’t even used in the project that was deployed, so why did octopus reject my deployment. And last but not least the above was not present in the release of 3.4.14 and before, so something did change in the validation.

What are your thoughts about it?

The error message came from: https://github.com/OctopusDeploy/Octostache/blob/master/source/Octostache/Templates/EvaluationContext.cs

Hi Rene,

Based on your description, I attempted to replicate your issue but I was unable.

Could you possibly provide screenshots of the relevant variable configurations? (Feel free to mark this thread as “Private” if you like).
Alternatively, if you can provide exact steps to replicate?

I assume from your description that this was working without issues before you upgraded to 3.5?

Regards,
Michael

I have narrowed it down to the following. I create a new VariableSet
I create a variable named MyVar and give it a value: #{MyVar.DoesNotExists} this results in the error message. If I don’t use the “prefix” #{DoesNotExists} it will parse just fine. This worked fine prior to 3.5

Thanks,
With your extra information we were able to identify the issue. It seems this was a bug we introduced in 3.5.

This has been resolved, and will ship with 3.5.1 which should be released today (or tomorrow at the latest).

Apologies for any inconvenience.

Regards,
Michael

Thanks for picking up and resolving this bug. Keep up the good work!