[BUG] TEST: Potential Bug — MPE error when not AuthZ on PE Azure resource (upstream #77)

[ayeshurun]

📋 Copied from microsoft/fabric-cli#77 for AI triage testing.
Expected triage outcome: Potential Bug

---

Bug Description

When a user is not authorized to read the Azure resource for which the Private Endpoint is created then the CLI gives a cryptic error even though the Managed Private Endpoint (MPE) gets successfully created (ofc still need to be approved).

fabric-cli version

1.2.0

Python version

Python 3.12.9

Operating System

Windows

CLI Mode

Command line mode

Authentication Method

Service principal (secret)

Steps to Reproduce

On an existing Fabric workspace create a Managed Private Endpoint on a Azure Resource using the CLI with a user that is not Authorized to read the private endpoints connections of that resource.

In my scenario I was creating a MPE to an Azure Key Vault with a SPN. The SPN has full admin rights to the workspace, but has no permissions on the AKV.

WORKSPACE_NAME="ws1.workspace"
PE_KEYVAULT_RESOURCE_ID="/subscriptions/XXXX/resourceGroups/myrg/providers/Microsoft.KeyVault/vaults/mykeyvault"
fab create ${WORKSPACE_NAME}/.managedprivateendpoints/mpe1.ManagedPrivateEndpoint \
    -P targetprivatelinkresourceid=${PE_KEYVAULT_RESOURCE_ID},targetsubresourcetype=vault
Creating a new Managed Private Endpoint. It may take same time (waiting until provisioned)...
x create: [UnknownError] An unexpected error occurred while processing the request
∟ Request Id: d631414d-b63e-4fcd-afbc-d739346772c8

This successfully creates the MPE, although this is unclear from the error. The error is caused here:
https://github.com/microsoft/fabric-cli/blob/7c7188c9633666ccd9a15fdbb1b1e6a922a84eca/src/fabric_cli/utils/fab_cmd_mkdir_utils.py#L736-L739

Traceback:

Traceback (most recent call last):
  File "", line 1, in 
  File "C:\Users\gfranssens\vscode-projects\fabric-cli\src\fabric_cli\client\fab_api_client.py", line 167, in do_request
    raise FabricCLIError(
fabric_cli.core.fab_exceptions.FabricCLIError: [Forbidden] Access is forbidden. You do not have permission to access this resource

HTTP Request response 403:

{
  "error": {
    "code": "AuthorizationFailed",
    "message": "The client 'XXX' with object id 'XXX' does not have authorization to perform action 'Microsoft.KeyVault/vaults/privateEndpointConnections/read' over scope '/subscriptions/XXX/resourceGroups/myrg/providers/Microsoft.KeyVault/vaults/mykeyvault' or the scope is invalid. If access was recently granted, please refresh your credentials."
  }
}

Expected Behavior

MPE was successfully created, however the status cannot be checked.

Actual Behavior

WORKSPACE_NAME="ws1.workspace"
PE_KEYVAULT_RESOURCE_ID="/subscriptions/XXXX/resourceGroups/myrg/providers/Microsoft.KeyVault/vaults/mykeyvault"
fab create ${WORKSPACE_NAME}/.managedprivateendpoints/mpe1.ManagedPrivateEndpoint \
    -P targetprivatelinkresourceid=${PE_KEYVAULT_RESOURCE_ID},targetsubresourcetype=vault
Creating a new Managed Private Endpoint. It may take same time (waiting until provisioned)...
x create: [UnknownError] An unexpected error occurred while processing the request
∟ Request Id: d631414d-b63e-4fcd-afbc-d739346772c8

Additional Context

No response

Possible Solution

Error handling when making the request to check the Azure resource.

[github-actions]

🅰️ Approach A (Action) — prompt-only, no codebase access

AI Assessment: Potential Bug

Completeness
The report provides all necessary details: reproduction steps, CLI version (1.2.0), Python version (3.12.9), OS (Windows), CLI mode (command line), authentication method (service principal, secret), and a clear expected vs actual outcome. The error message, relevant traceback, HTTP response, and a suspected code location are provided.

Plausibility
The described behavior is plausible given the CLI's use of Azure APIs to validate Managed Private Endpoint creation and status. When the service principal lacks permission on the target Azure resource, Azure returns a 403/AuthorizationFailed. Instead of a clear explanation, the CLI emits "UnknownError" while the MPE is still created successfully. The referenced code section appears to not distinguish between errors during status polling vs creation, resulting in a misleading surface error.

Severity
This is not a direct data-loss or security flaw, but it impacts usability and customer experience. Users may believe creation failed due to the error, which could disrupt workflows. Error handling should distinguish between creation and status-check permission failures, and message the outcome accurately.

Next Steps
🔔 Escalated to team — This issue requires team review and has been flagged for attention.

---

💡 If this issue requires the team's attention and was not escalated, you can tag @microsoft/fabric-cli-dev to notify the team.

---

🏷️ Label Decisions (testing mode — not applied)

Decision	Value
AI assessment	ai:bug-triage:potential bug
Would add help wanted	❌
Would add ai:needs team attention	✅
Would request author feedback	❌
Would remove needs triage	❌
Would auto-close	❌
Would notify team	✅

[github-actions]

🅱️ Approach B (Code Agent) — code-aware triage agent that reads the actual source code

AI Assessment: Potential Bug

Completeness

The report provides clear reproduction steps, includes fabric-cli version, Python version, OS, CLI mode, and authentication method. Both expected and actual behaviors are described, with a CLI transcript and error details including HTTP 403 response and traceback. The underlying cause is referenced with a code link. This is sufficient for triage.

Plausibility

The described behavior aligns with the CLI's use of Azure REST APIs and error handling. When creating a Managed Private Endpoint (MPE) targeting an Azure Key Vault, the CLI attempts to verify the endpoint connection status, which requires additional Azure authorization. The service principal lacks permissions on the Key Vault, resulting in a "Forbidden" error despite successful creation. The error messaging does not clarify that the creation succeeded and only the status check failed, leading to user confusion.

Severity

This does not appear to be a data-loss or security vulnerability, but impacts user experience and error clarity. The cryptic error hides the successful creation of the MPE, which may cause users to retry or misinterpret outcomes. Improved error handling and messaging are warranted to distinguish between creation failures and permission limitations for status checks.

Recommendation

Error handling for MPE creation should be adjusted to make it clear when creation succeeds but status checks fail due to insufficient Azure permissions. The CLI should report the partial success and advise on next steps, possibly referencing required Azure RBAC roles. This issue is valid and requires developer investigation and changes in error reporting logic.

Next Steps
🔔 Escalated to team — This issue requires team review and has been flagged for attention.

---

💡 If this issue requires the team's attention and was not escalated, you can tag @microsoft/fabric-cli-dev to notify the team.

---

🏷️ Label Decisions (testing mode — not applied)

Decision	Value
AI assessment	Potential Bug
Would add help wanted	❌
Would add ai:needs team attention	✅
Would request author feedback	❌
Would remove needs triage	❌
Would auto-close	❌
Would notify team	✅

[github-actions]

🅰️ Approach A (Action) — prompt-only, no codebase access

AI Assessment: Potential Bug

The report describes a scenario where the user receives a cryptic or misleading error message after successfully creating a Managed Private Endpoint, due to insufficient permissions on the target Azure resource (e.g., Key Vault). The error returned is generic ("UnknownError"), even though the operation itself proceeds as expected, lacking detail on what is actually blocked (status reading, not creation).

This behavior does not align with standard CLI error handling, which should distinguish between resource creation success and permission issues related to status/read actions. Displaying an ambiguous error may confuse users about the outcome and mask the nature of the permission error (HTTP 403 AuthorizationFailed). The CLI should clarify which action failed and whether the initial creation was successful, particularly for complex Azure operations where post-creation steps (approval/status) depend on further access.

The linked code segment indicates inadequate error mapping for this specific scenario. Improving user feedback would involve a more granular check and reporting, with clear separation between creation and subsequent resource access failures.

Next Steps

🔔 Escalated to team — This issue requires team review and has been flagged for attention.

---

💡 If this issue requires the team's attention and was not escalated, you can tag @microsoft/fabric-cli-dev to notify the team.

---

🏷️ Label Decisions (testing mode — not applied)

Decision	Value
AI assessment	ai:bug-triage:potential bug
Would add help wanted	❌
Would add ai:needs team attention	✅
Would request author feedback	❌
Would remove needs triage	❌
Would auto-close	❌
Would notify team	✅

[github-actions]

🅱️ Approach B (Code Agent) — code-aware triage agent that reads the actual source code

AI Assessment: Potential Bug

The CLI's error messaging in this scenario is misleading. When a Managed Private Endpoint (MPE) is created targeting an Azure resource for which the user lacks privateEndpointConnections/read permission, the underlying creation succeeds, but the CLI reports a cryptic error and appears to fail. The exception originates from a downstream call to the Azure API that attempts to check PE connections, which returns 403 Forbidden. This results in an "UnknownError" message, obscuring the fact that the MPE creation was successful and only approval/status checks failed.

This behavior deviates from expected UX for resource creation operations. Users should receive clear feedback distinguishing between creation success and inability to query resource status due to Azure authorization constraints. RFC 7807 and Microsoft REST API Guidelines recommend precise error messaging and surface actionable details; this implementation does not comply.

The affected code path is referenced (fab_cmd_mkdir_utils.py), which confirms the error handling does not adequately account for partial success scenarios. Improving error handling to detect and communicate Azure permission failures without masking the primary operation's outcome is necessary. The severity is moderate given it impacts clarity for automation and user operations but does not cause data loss or security exposure.

Next Steps
🔔 Escalated to team — This issue requires team review and has been flagged for attention.

---

💡 If this issue requires the team's attention and was not escalated, you can tag @microsoft/fabric-cli-dev to notify the team.

---

🏷️ Label Decisions (testing mode — not applied)

Decision	Value
AI assessment	Potential Bug
Would add help wanted	❌
Would add ai:needs team attention	✅
Would request author feedback	❌
Would remove needs triage	❌
Would auto-close	❌
Would notify team	✅

[github-actions]

🅰️ Approach A (Action) — prompt-only, no codebase access

AI Assessment: Potential Bug

The CLI displays an "UnknownError" when attempting to create a Managed Private Endpoint with an SPN lacking permissions to read the target Azure resource's private endpoint connections. However, the endpoint is actually created, but approval and status cannot be verified due to the permission issue. The error message is cryptic and incorrectly implies creation failed, whereas only the status check is blocked.

The reported HTTP 403 response from the Azure API is a known scenario, but the CLI does not differentiate between a fatal creation failure and a permission issue during post-creation status checks. It surfaces a generic "UnknownError" instead of a more informative "Access forbidden" or "Partial success" message. This behavior could mislead users into thinking the operation failed entirely, which diverges from expected CLI error handling for resource actions, particularly when partial success is achieved.

Improved error handling in the CLI should clarify that the MPE was created, but subsequent status/approval checks failed due to insufficient permissions. Referring to the error code returned (Forbidden/AuthorizationFailed) or surfacing more granular error context would align with typical CLI conventions and improve user experience.

Next Steps

🔔 Escalated to team — This issue requires team review and has been flagged for attention.

---

💡 If this issue requires the team's attention and was not escalated, you can tag @microsoft/fabric-cli-dev to notify the team.

---

🏷️ Label Decisions (testing mode — not applied)

Decision	Value
AI assessment	ai:bug-triage:potential bug
Would add help wanted	❌
Would add ai:needs team attention	✅
Would request author feedback	❌
Would remove needs triage	❌
Would auto-close	❌
Would notify team	✅

[github-actions]

🅱️ Approach B (Code Agent) — code-aware triage agent that reads the actual source code

AI Assessment: Potential Bug

The report describes a scenario where the CLI gives a misleading error when creating a Managed Private Endpoint (MPE) on an Azure resource for which the user lacks read permissions. The CLI communicates an "UnknownError" or access forbidden error even though the creation of the MPE succeeds, leaving users confused about the actual outcome.

The implementation in fab_cmd_mkdir_utils.py appears to run a status check (likely polling the private endpoint's Azure resource) post-creation, and if this check fails due to lack of authorization, the CLI raises a generic error. However, this does not correspond to a failure in MPE creation, but rather a failure to poll or fetch its status. This violates best practice for CLI error reporting, which should clearly distinguish between operation success and auxiliary post-operation failures (see Troubleshooting). Unclear error messaging in resource creation flows can mislead users about the state of their environment, especially in security and networking contexts.

As this impacts both user experience and proper status reporting for MPE creation, and may lead to confusion or repeated actions with network and auth implications, further investigation is warranted to revise error handling and message surfacing around post-create polling/status checks.

Next Steps

🔔 Escalated to team — This issue requires team review and has been flagged for attention.

---

💡 If this issue requires the team's attention and was not escalated, you can tag @microsoft/fabric-cli-dev to notify the team.

---

🏷️ Label Decisions (testing mode — not applied)

Decision	Value
AI assessment	Potential Bug
Would add help wanted	❌
Would add ai:needs team attention	✅
Would request author feedback	❌
Would remove needs triage	❌
Would auto-close	❌
Would notify team	✅