az monitor diagnostic-settings create claims 200 response but no diagnostic settings added to logic app

[banani720]

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

Related command

az monitor diagnostic-settings create --resource {} -n {} --resource-group {} --workspace {}

Describe the bug

I am being presented with a resource ID but when I attempt to verify the creation of the diagnostic setting in the portal I am not shown that any diagnostic settings exist on my logic app. Furthermore, az monitor diagnostic-settings list --resource {} using logic app resource ID provides [] output.

To Reproduce

Run az monitor diagnostic-settings create command
Try to view in the portal after diagnostic settings JSON output is shown
Try to list the diagnostic settings on logic app resource using az monitor diagnostic-settings list --resource {}

Expected behavior

I would expect to find a diagnostic setting in the Diagnostic Settings pane for my logic App, and I would expect that az monitor diagnostic-settings --resource {} would indicate that a diagnostic setting exists for that resource.

Environment summary

az cli 2.43.0
Windows 10

Additional context

Ran the command with --debug flag and can confirm that the PUT operation associated with the creation of the diagnostic setting returns a 200 response.

Edit
Thought I should provide an edit/update to the discovery on this issue. We were able to finally get the expected diagnostic setting to show in the portal BUT it required the use of the --logs or --metrics flag in order to actually render that. The docs in no way mention that either of these flags are required and specify them optional. I guess what would be valuable to know is:

a) without either of these flags is the Diagnostic Setting actually being created on the resource? If yes, is it being then subsequently deleted because no logging or metric measuring are taking place?

b) If the resource is not actually being created should the messaging on the command be changed to reflect that as opposed to showing apparent success, as well as the docs associated with the command. The debug flag on the command shows as follows when --logs and --metrics are not provided:

cli.azure.cli.core.sdk.policies: Response status: 200
cli.azure.cli.core.sdk.policies: Response headers:
cli.azure.cli.core.sdk.policies:     'Cache-Control': 'no-cache'
cli.azure.cli.core.sdk.policies:     'Pragma': 'no-cache'
cli.azure.cli.core.sdk.policies:     'Transfer-Encoding': 'chunked'
cli.azure.cli.core.sdk.policies:     'Content-Type': 'application/json; charset=utf-8'
cli.azure.cli.core.sdk.policies:     'Content-Encoding': 'gzip'
cli.azure.cli.core.sdk.policies:     'Expires': '-1'
cli.azure.cli.core.sdk.policies:     'Vary': 'Accept-Encoding'
cli.azure.cli.core.sdk.policies:     'Strict-Transport-Security': 'max-age=31536000; includeSubDomains'
cli.azure.cli.core.sdk.policies:     'x-ms-request-id': '7eabe9a7-5502-4c24-94d8-d533e56ac292'
cli.azure.cli.core.sdk.policies:     'Server': 'Microsoft-IIS/10.0'
cli.azure.cli.core.sdk.policies:     'x-ms-ratelimit-remaining-subscription-resource-requests': '149'
cli.azure.cli.core.sdk.policies:     'x-ms-correlation-request-id': '93d4f7c5-f3c3-4698-830f-3800d5a109d0'
cli.azure.cli.core.sdk.policies:     'x-ms-routing-request-id': 'WESTUS2:20230103T223752Z:93d4f7c5-f3c3-4698-830f-3800d5a109d0'
cli.azure.cli.core.sdk.policies:     'X-Content-Type-Options': 'nosniff'
cli.azure.cli.core.sdk.policies:     'Date': 'Tue, 03 Jan 2023 22:37:51 GMT'

[yonzhan]

@AllyW for awareness