az cli version 2.0.74 commands write to stderr stream even when the command succeeds

[tejasd1990]

az feedback auto-generates most of the information requested below, as of CLI version 2.0.62

We own the "Azure CLI" Azure Pipelines task.
We have come across 3 customer issues so far where az cli version 2.0.74 commands write to stderr stream even when the command succeeds
Could be happening since some other older version, I don't know about that, but see this issue with at least this version.

Describe the bug
We have come across 3 customer issues so far where az cli version 2.0.74 commands write to stderr stream even when the command succeeds
At line:1 char:1

• az extension add --name application-insights --output none 2>&1

•   + CategoryInfo          : NotSpecified: (WARNING: Extens...eady installed.:String) [], RemoteException
    + FullyQualifiedErrorId : NativeCommandError
  
  

To Reproduce
For example,
az extension add --name application-insights --output none 2>&1

Expected behavior
successful commands should not write to stderr stream

Environment summary
Azure Pipelines Hosted Agent, Powershell on my local machine

Additional context
Add any other context about the problem here.

[dmitrykarnitski]

Hi, We have experienced this issue as well.

But according to the reply from this comment (#9891 (comment)), this is the expected behavior.

So, what is the right approach?
IMO, the error stream should not contain any garbage that is not really related to errors happened during the execution.

[yonzhan]

@jiasli please take a look.

[jiasli]

It is by-design to write warnings to stderr. To remove the warning, on Windows use

az extension add --name application-insights --output none 2>nul

On Linux use

az extension add --name application-insights --output none 2>/dev/null

[tvanfosson]

@jiasli using Azure DevOps pipelines to execute scripts it is common to turn on "Fail on Standard Error" because commands don't always exit with a non-zero value. Having Azure CLI commands output non-fatal errors to stderr makes it much more difficult to capture actual errors from CLI commands while still dealing with other script elements that don't behave nicely in other ways.

[yonzhan]

Can we close this issue?