I’m just looking for clarification on how PSU would behave in a specific scenario, as part of troubleshooting.
If we have a Secret variable defined called “APIKey” and then we use a mostly pre-configured script that has a line “$APIKey = $Secret:APIKey”, would PSU be smart enough to know that “$APIKey” is NOT referring to the secret named “APIKey” (as in, it would see that there is not a normal variable named APIKey, and be able to use $APIKey as a variable that only exists within the script? Or, would PSU see that there is a variable named “APIKey” regardless of its type (normal or secret), and thus cause a recursive variable lookup?
The reason I’m asking this, as I mentioned, is part of some troubleshooting. We have a script that, when run MANUALLY, works 100% of the time; the same script run as part of a scheduled job, sits in a “Waiting for Feedback” state until we supply the API key manually to allow it to continue running.
The only part of the script I can find that might explain this behavior is where there’s a scenario as I described above. I’ve made a new Secret variable with a different name and changed the script to use that, to see if my theory pans out, but I can’t wrap my head around how the script works fine when run manually and only messes up when it’s a scheduled job… unless PSU processes things differently in both of those methods for some reason.
My theory seems to have been proven, as the script ran as a scheduled job after having made the new Secret variable and changing the script to use it.
I’m still confused how the script would work without fail if it was run manually and only failed when run as a scheduled job. Someone please help me figure that piece out.
not sure you need to assign it , just use it like this
Get-somefunction -Token $Secret:ApiKey -Verbose
unless ive misunderstood what you are doing , some example code would help to understand…
1 Like
Thanks, but I’m not in need of help in that sense. Yes, I know it’s stupid to even have the script configured that way in the first place - I wasn’t the one that did it or gave the initial variable its name. I just want to know how PSU would behave in the scenario I presented in the initial post (whether PSU is smart enough to know that the variable being referenced either is or isn’t a Secret variable.
To help explain it, it may be simpler to ask what PSU would do if it had 2 variables defined with the same name, with 1 of them being a normal variable and 1 of them being a Secret variable. In the actual admin console, you’re prohibited from having duplicated variable names regardless of the types being different, so I’m guessing that this explains the problem (that I was right in thinking PSU would become confused with a variable being called as both a normal/standard variable but then also being called as a Secret variable within a script), creating a recursive lookup.
What I am trying to figure out, assuming that my theory is correct, is how the script runs without any failures or issues if it’s run manually inside of PSU, but fails (waits for feedback (i.e., the user/admin to enter the API key) when run as a scheduled job (with absolutely zero alterations).
At this point, as I mentioned previously, I’ve already made a new Secret variable with the same value, with a new name, and modified the code to use that new variable instead of the one using the same name as the variable already referenced throughout the script. The scheduled job ran without the failures we had previously seen, so I think it’s resolved at this point. However, I’d still like to have some sort of confirmation on how PSU would behave in such a scenario.
so my understanding is that the Secret: is a kind of special scope availiable inside PSU that is similar but separate to how scopes work in powershell , I think the variables full name is the scope plus the name and thats is why both can co-exist in the same script inside PSU , but “standard” powershell wont know about the secret scope
Despite that potentially being the case, it still leaves me stuck at determining why the script works when run manually but fails when run automatically (as a scheduled job), assuming you’re correct that “$APIKey” (only a variable within the script itself) and “$Secret:APIKey” (a variable in PSU that is referenced within the script) are seen as 2 separate variables (because they’re in different scopes).