[power-automate][Bug] FlowAgent PPAPI calls fail with "fetch failed" against tenant-default environments

[gphillipsHRI]

Plugin

power-automate

Plugin Version

2.0.0

Skill / Command

N/A (FlowAgent MCP tools: list_flows, list_connections, list_connectors)

Bug Description

Tools that route through the PPAPI per-environment endpoint (environment.api.powerplatform.com) — e.g. list_flows, list_connections, list_connectors — fail with a generic {"code":"tool-error","message":"fetch failed","errorName":"TypeError"} when called against a tenant-default environment (one whose environment ID has the form Default-<tenantId> rather than a plain GUID). Tools that route through the older Flow RP API (e.g. list_environments) work fine against the same environment.

Root cause: ppapiBaseUrl(envId) builds the per-environment PPAPI hostname by stripping dashes from envId and hex-slicing it into a 30+2 character split ({prefix}.{shard}.environment.api.powerplatform.com). This assumes envId is always a raw GUID. For tenant-default environments, both the Flow RP and BAP APIs return the environment ID as the literal string Default-<tenantId>, not a GUID. Stripping dashes from that string produces a hostname containing the literal characters "Default" mixed with hex digits, which is not a real subdomain and never resolves in DNS (confirmed directly via dns.resolve4() → ENOTFOUND).

I also tried substituting other GUIDs Microsoft's APIs expose for this same environment (the Dataverse organizationid, and the bare tenant ID with the Default- prefix stripped) into the same hex-slice scheme — none of them resolve either, so there may not be a PPAPI per-environment host available for this class of environment at all.

I confirmed the same flow data IS reachable through the legacy Flow RP API (api.flow.microsoft.com/providers/Microsoft.ProcessSimple/environments/{envId}/flows) using a normal access token — it returns 200 with the full flow list.

Steps to Reproduce

1. Have a tenant whose default environment ID is the alias form Default-<tenantId> (this is standard for any tenant's default environment, not an unusual configuration).
2. Call list_flows (or list_connections / list_connectors) with env set to that environment ID.

Expected Behavior

The tool returns the flows/connections/connectors in that environment, same as it does for a normal GUID-named environment.

Actual Behavior

The call fails every time with:

{"code":"tool-error","message":"fetch failed","errorName":"TypeError"}

The identical account/token succeeds against a different (GUID-named) environment in the same tenant, and list_environments itself succeeds for the default environment — only PPAPI-routed calls fail.

Relevant Logs / Screenshots

Hostname the tool derives for the default environment (dashes stripped from Default-<tenantId-placeholder>):
Defaultxxxxxxxxxxxxxxxxxxxxxxxxx.xx.environment.api.powerplatform.com → DNS ENOTFOUND

Suggested fix: when the derived PPAPI hostname fails to resolve (or when envId matches the Default- alias pattern), fall back to the Flow RP endpoint for read operations (listFlows, getFlow) and consider the same fallback for write operations (createFlow, updateFlow), since Flow RP supports the same CRUD surface.

Environment

• OS: Windows 11 (MINGW64/Git Bash)
• Claude Code version: 2.1.214
• Node.js: v24.18.0

---

🤖 This issue was created using the /report-issue skill.

[DSerrano-AI]

Think this might be the same root cause we hit and diagnosed in #333 — a Default-<tenantId> environment's per-environment PPAPI hostname is missing a literal default prefix that ppapiBaseUrl() strips and never restores. Tested a one-line fix against our own tenant and it resolved every connector/connection tool that was failing this way (plus the flow-side ones, without needing the #284 fallback at all).

Full diagnosis + patch + live-test results here, in case it saves some digging: #333 (comment)

[radioblazer]

Fixed in v3.0.1 — resolved in PR #393, merged 2026-08-12.

Please update to v3.0.1 and let us know if you're still seeing this.