An attempt to parse the variable symbol appears to have resulted in a self referencing loop. Ensure that recursive loops do not exist in the variable values

Hi,

I have an issue reported that give the below error:
An attempt to parse the variable symbol “MutualisedParcelGroupReferentLab” appears to have resulted in a self referencing loop (MutualisedParcelGroupReferentLab → MutualisedParcelGroupReferentLab). Ensure that recursive loops do not exist in the variable values.

A number of deployments have failed with this error. This is an intermittent issue.

I can upload the deployment log if you need the investigate further.

Kind Regards,
Micheál Power

Good morning @mikepower79,

Thank you for contacting Octopus Support and sorry to hear you are seeing this error when trying to deploy some of your projects, it is odd this is intermittent, do you mean its intermittent across projects (ie some will have the error and some wont) or is it the same deployment (ie if you re-deploy the failed deployment does it then deploy fine)?

The issue seems to be related to an issue where variables inside your project or a connected LibraryVariableSet share a value or evaluate to the same value of another variable name.

I found a few previous tickets in with the same error and there are three (old) GitHub issues in for this but I believe you are on a version a lot higher than 2019.x arnt you so I imagine you are not hitting those specific bugs:

From the looks of the error it is the variable MutualisedParcelGroupReferentLab that has the issue.

There are a few fixes that were used in previous tickets I will outline here in case one of these works for you:

  • Instead of limiting the variable in question to only one or a few environments, change it to work in all environments and see if you can re-deploy.
  • Ensure that variable does not have a value or a value that evaluates to the name of another variable. The easiest way to do that is to download your deployment process as JSON (in the overflow menu of the process page). Open it and look for the Properties item under each Action. Look for any variable expressions. Then use the VariablesAll page to figure out whether that variable will resolve to the name of another variable. (There is an example of this in the first GitHub issue I posted up above).
  • One person renamed the variable in question and that seemed to fix the issue.

I would say I would look into fix 2 first, since we have had no other reports of this in later Octopus versions after 2019.x I would hazard a guess this is not another re-introduced bug but it is the case that your MutualisedParcelGroupReferentLab is being evaluated to the same value in another variable. If you try fix 2 first and that does not show that I would try fixes 1 and 3. Fix 3 would be the easiest but it depends if this works for you and if you are happy to change the name of that variable.

Let me know if you need further clarification on this as it took me a few attempts to get my head around what the issue actually was from previous tickets, also let me know if none of those fixes work and I can look into other options for you.

Kind Regards,
Clare

Hi @clare.martin,
Thanks for the quick response.
Sorry I forgot to mention we are on version 2022.4.8505.

I will have a look at the fixes you mentioned.

This issue seems to be on one project.

Kind Regards,
Micheal Power

Hey @mikepower79

No worries, I knew you were on a 2022.x version from previous tickets so assumed you would not be running into those bugs but it may just be your variable name is actually evaluated to the same variable value somewhere in that project, at least it is just one project so you only have to check that one.

Let me know if any of those fixes work for you.

Kind Regards,
Clare

1 Like

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