You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I am currently building an vault extension module, and I'm struggling to get meaningful logging/output to the end user.
Using Get-Secret -Verbose works when the extension only hits Write-Verbose messages. However, if it encounters a terminating error via throw, it seems none of the verbose messages are output, even if those verbose messages came before the Throw. For end users this confusion gets compounded because Get-Secret generalizes the message thrown by the extension vault, and you have to dig into $Error[1].Exception.InnerException.Message to find the real error message.
Would it be possible to ensure Write-Verbose is always written? Am I just missing some sort of best practice here? I've read through the documentation and it seems to suggest that simply checking for $AdditionalParameters.Verbose and setting $VerbosePreference is the intended way of handling this.
For example, lets take this chunk of pseudo-code
functionGet-Secret {
[CmdletBinding()]
param ( <#Standard params here#> )
if ($AdditionalParameters.Verbose-eq$true) {
$VerbosePreference='Continue'
}
Write-Verbose'Attempting to get secret'#Actions to retrieve secretif ($Secret.count-gt1) {
Throw'Multiple ambiguous results, please refine search'
}
return$Secret
}
Expected behavior
When running against a secret that does only have 1 value and is not ambiguous, the function behaves as expected, like this
PS > Get-Secret -Name 'Only1Exists'VERBOSE: Attempting to get secretVERBOSE: Secret Only1Exists was successfully retrieved from vault VaultName.System.Security.SecureString
Similarly, when running the same command that does cause the ambiguous throw condition, I would expect the following:
PS > Get-Secret -Name '2Exist'VERBOSE: Attempting to get secretGet-Secret: Multiple ambiguous results, please refine search
Actual behavior
PS > Get-Secret -Name '2Exist'Get-Secret: Unable to get secret 2Exist from vault VaultNameGet-Secret: The secret 2Exist was not found.
Error details
No response
Environment data
Name Value
---------
PSVersion 7.2.6
PSEdition Core
GitCommitId 7.2.6
OS Microsoft Windows 10.0.19042
Platform Win32NT
PSCompatibleVersions {1.0,2.0,3.0,4.0…}
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1
WSManStackVersion 3.0
Version
N/A
Visuals
No response
The text was updated successfully, but these errors were encountered:
Prerequisites
Steps to reproduce
I am currently building an vault extension module, and I'm struggling to get meaningful logging/output to the end user.
Using Get-Secret -Verbose works when the extension only hits Write-Verbose messages. However, if it encounters a terminating error via throw, it seems none of the verbose messages are output, even if those verbose messages came before the Throw. For end users this confusion gets compounded because Get-Secret generalizes the message thrown by the extension vault, and you have to dig into $Error[1].Exception.InnerException.Message to find the real error message.
Would it be possible to ensure Write-Verbose is always written? Am I just missing some sort of best practice here? I've read through the documentation and it seems to suggest that simply checking for $AdditionalParameters.Verbose and setting $VerbosePreference is the intended way of handling this.
For example, lets take this chunk of pseudo-code
Expected behavior
When running against a secret that does only have 1 value and is not ambiguous, the function behaves as expected, like this
Similarly, when running the same command that does cause the ambiguous throw condition, I would expect the following:
Actual behavior
Error details
No response
Environment data
Version
N/A
Visuals
No response
The text was updated successfully, but these errors were encountered: