Unsupported underscores in variables.yaml in Axon Ivy 12

mhoffmann

I am honestly not sure whether this is a bug or a feature, but since Axon Ivy 10, we're using variables with underscores in the variables.yaml

We're now getting the error:

Variable 'PRE_NAME' contains a character that makes it unable to be accessed using "ivy.var.<variable>": Invalid character _ at position 4 in PRE_NAME.

This behaviour is neither documented in the migration guide, nor in the documentation itself.

First of all, I think this should be documented in the migration guide itself with all its implications, further, I'd argue that underscores in keys are somewhat common and a matter of taste, not best practice. I don't see any reason why they shouldn't be supported.

mhoffmann

I am even more confused by the error given from the parser, because it's not true to begin with (at least in the designer):

Am I missing something here or is the parser message just wrong? In 10 I only got the message Not ivy.var field compliant - but since everything works, I wonder what the reason for these messages even is? It's valid YAML and I'm utterly confused now.

Lukas Lieb

Hi @mhoffmann

Your totally right! We also detect this problem an created a story for it: XIVY-17098. It should be fixed for v14 and the next v12 LTS version.

Elio Di Puma

Hi @mhoffmann
Thanks for raising this, you’re absolutely right that variables with underscores like ivy.var.MY_VAR generally work and are supported.

The reason we introduced a warning is related to how variable resolution works internally. Underscores are also used by the API to separate namespaces, which can lead to ambiguity. For example, if you have a variable named MY_VAR and also a variable VAR inside a namespace MY, both would resolve to ivy.var.MY_VAR. In that situation, we can’t reliably determine which variable is meant.

So the warning is not about underscores being invalid, but about preventing these ambiguous cases.

That said, I agree that the current warning message is misleading because it suggests underscores are generally unsupported, which isn’t true.

We have improved this behavior so that a warning is no longer shown just because a variable contains an underscore. It now only appears if there is an actual ambiguity like the one described above and the message itself has been updated to better explain the situation.