Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Inconsistent behaviour of -Verbose when encountering Throw #205

Open
3 tasks done
EmeraldFlame opened this issue Aug 17, 2022 · 1 comment
Open
3 tasks done

Inconsistent behaviour of -Verbose when encountering Throw #205

EmeraldFlame opened this issue Aug 17, 2022 · 1 comment

Comments

@EmeraldFlame
Copy link

EmeraldFlame commented Aug 17, 2022

Prerequisites

  • Write a descriptive title.
  • Make sure you are able to repro it on the latest released version
  • Search the existing issues.

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

function Get-Secret {
  [CmdletBinding()]
  param ( <#Standard params here#> )

  if ($AdditionalParameters.Verbose -eq $true) {
    $VerbosePreference = 'Continue'
  }

  Write-Verbose 'Attempting to get secret'
  #Actions to retrieve secret
  if ($Secret.count -gt 1) {
    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 secret
VERBOSE: 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 secret
Get-Secret: Multiple ambiguous results, please refine search

Actual behavior

PS > Get-Secret -Name '2Exist'
Get-Secret: Unable to get secret 2Exist from vault VaultName
Get-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

@Callidus2000
Copy link

Hi,
maybe this can help:
I've included a workaround in my template module and in the corresponding ReadMe.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants