Relevance substitution evaluation strangeness

I have a custom task in a custom site that I’ve used for years, and in it there is simple session relevance like this:

if {value of setting “test” of client as integer >=3}
setting “blah”=“yes” on “{now}” for client
endif

even if setting “test” doesn’t exist, this always worked with no session relevance errors, but now I’ve copied the task and am trying to make update to it and now every session relevance is erroring out with “relevance substitution error”. Why is this happening all of a sudden on a new task, when it didn’t do that with my old task?

This looks like client relevance to me, but I think something like the below might work better for you (it shouldn’t error out if the setting does not exist):

if {exists values whose (it as integer >= 3) of settings "test" of client}

Another option would be to use the pipe inspector to handle the error condition for you:

if {(value of setting "test" of client as integer >=3) | false}
1 Like

Hi Aram, you’re right (relevance substitution is what I meant). Any reason why this would happen all of the sudden with a new task?

What is the minimum client version that supports pipe? I though that was new in v8 or v9?

That’s right, the pipe inspector was introduced with v8.0. If you have older clients still in the environment, the other approach I have above should work.

I’ll try that, but even a relevance like this is failing (and it’s worked before), where I check the exit code. Obviously that will never successfully evaluate before the action is ran, so that’s why I’m so confused why all of this sudden this is happening.

if {name of operating system as lowercase contains “win”}
waithidden cmd.exe /c command123
continue if {exit code of it = 0}
else if {name of operating system as lowercase contains “linux”}
run sh -c command123
continue if [exit code of it = 0}
endif

Two things I see potentially wrong…

One, exit code of it is not valid. The it is a variable so you need exit code of action for this to be valid.

Second, which phase is it failing on? In the check for downloads, the exit code of action may not be understood as an action must be running (not just evaluating the actionscript for downloads)

I use the following to get around that scenario

continue if {exists true whose (if true then (exit code of action = 0) else false)}
1 Like

Hi, you’re right, i missed the “… of action” when I posted the in the forum thread, but my code did have it in the task.

It’s just strange that I’m getting a relevance substitution error all of the sudden with {exit code of action = 0} in my new task, but an older task that has successful runs used the same exit code relevance substitution without any issues. Can you explain that? It’s like all of the sudden there’s some trigger that forces relevance substitution to error out.

if {(exists service "MSiSCSI" whose (state of it = "Running")) AND (exists value "PowerShellVersion" whose (it as  string = "2.0") of key "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PowerShell\1\PowerShellEngine" of registry) AND (not exists file (value of variable "SystemDrive" of environment & "\supportfiles\iemdata\iscsi_persist.txt")) OR (exists file (value of variable "SystemDrive" of environment & "\supportfiles\iemdata\iscsi_persist.txt") whose (modification time of it > (now-28*day)))}
	prefetch e9c48f6dffefa853b9556773fe2a9bac8f74d725 sha1:e9c48f6dffefa853b9556773fe2a9bac8f74d725 size:1823 http://url:52311/Uploads/e9c48f6dffefa853b9556773fe2a9bac8f74d725/iSCSI_persist.ps1.tmp
	extract e9c48f6dffefa853b9556773fe2a9bac8f74d725

	parameter "PowerShellexe"="{value "Path" of key "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PowerShell\1\ShellIds\Microsoft.PowerShell" of native registry}"

	waithidden "{parameter "PowerShellexe"}" -executionpolicy remotesigned __Download\iSCSI_persist.ps1 –evaluate
	continue if {exit code of action = 0}
endif

here’s another example of it happening,

action script #1 for server abc:
Failed parameter “slash”="{(if (name of operating system as lowercase contains “win”) then “” else “/”)}"

action script #2 for server abc:
Completed parameter “slash”="{(if (name of operating system as lowercase contains “win”) then “” else “/”)}"

Why would relevance substitution fail for one task and succeed for another, when the relevance is the same?

Do you have a client log showing the error?

Also if you’re trying to determine which slash to use then you can do one of two things, use different relevance to create a path ( pathname of of of etc ) as the language does it right, or secondarily, Windows is pretty happy about accepting “C:/Windows/System32” etc as a path in this form

1 Like

hi AlanM, sure, i could do that workaround of allowing the forward slash to be used in Windows, but I need to know why a relevance subsitution error occurs on something as simple as…

(if (name of operating system as lowercase contains "win") then "\" else "/")

…in one task, but works in another task.

It must not just be me because here’s another post with the same issue…

Maybe try to encapsulate it all with a “as string” suffix?

parameter "slash"="{(if (name of operating system as lowercase contains "win") then "\" else "/") as string}"

The as string shouldn’t matter as the result of a relevance substitution is to coerce to a string so that is a bit redundant.

Are there differences in the OS for the machines that work or not?

no differences. It’s strange, the old action worked fine, this new action fails , but then I can push the new task again and it seems to work periodically, like the parameter relevance works dependent on a last action run.

In the “new” action are you defining the parameter more than once? What is the difference between the actions you tried?

1 Like

no, line 1 is the same in the old action as the new action, and i’m only defining the parameter “slash” once.

The second action has many more if/then logic to it because all the “IF” session relevance statements go into error, which is also different than the original task. I didn’t need to do logic if a file exists in an if {} statement, it just worked.

for example, this IF statement worked in the task without relevance substitution error:

if {value of setting "SMSyncFail" of client as integer >=3}

but with this new task, it would give a relevance substitution error, so I had to convert that line to this:

if {if (exists setting "SMSyncFail" of client) then (if (exists value of setting "SMSyncFail" of client) then (value of setting "SMSyncFail" of client as integer >=3) else true) else false}

It’s always good practice in code to check for the existence of something before trying to access its properties. You can shorten up your new Relevance statement by using a whose/it clause.

exist setting “SMSyncFail” whose (value of it as integer >= 3) of client

1 Like

true, all good points. but it sounds like no one can answer why

parameter "slash"="{(if (name of operating system as lowercase contains "win") then "\" else "/") as string}"

would fail, correct? I’m wondering if it is a bug in the 9.0.853.0 Root server.

Sure does work for me in the debugger. Could be a difference in the system that is attempting to set the parameter. Try this…

if (windows of operating system) then ("") else ("/")

strange thing is that it works fine in fixlet debugger too on the endpoint, but still complains in the action results.

i guess one difference in the old task from the new task is the new task has a prefetch/download command in it, Could that be causing the relevance substitution to be evaluated differently?