[power-automate][Bug] list_connections/invoke_operation build an invalid PPAPI hostname from a valid environment GUID (ENOTFOUND)

[DSerrano-AI]

Bug description

ppapiBaseUrl() in plugins/power-automate/server/mcp.mjs (v2.2.0) derives the Power Platform API hostname purely by string-slicing the environment GUID:

function ppapiBaseUrl(envId, templateOverride, suffixOverride) {
  const rawId = envId.replace(/^Default-/i, "");
  const hex = rawId.replace(/-/g, "");
  const prefix = hex.slice(0, 30);
  const shard = hex.slice(30, 32);
  ...
  return `https://${prefix}.${shard}.${suffix}`;
}

This produces a hostname that does not exist in DNS for our environment.

Steps to reproduce

1. Set the current environment to a valid Dataverse environment, e.g. env: "Default-<your-environment-guid>".
2. Call list_connections (or invoke_operation) against that environment.

Actual result

Flow API 0 NetworkError: Network request failed: ENOTFOUND (hostname: <prefix>.<shard>.environment.api.powerplatform.com). This often means the environment ID produced an invalid PPAPI URL. Verify the environment ID is a valid GUID.

Confirmed with a valid, correctly-formatted environment GUID (both plain GUID and Default-<guid> forms) — not an input-formatting issue.

Expected result

list_connections/invoke_operation should resolve the correct regional Power Platform API endpoint for the given environment (presumably via a real environment/instance lookup) rather than a static hex-slice of the GUID, and return connection data.

Environment

• Plugin: power-automate (power-platform-skills marketplace), v2.2.0
• Dataverse environment type: Default (non-Sandbox)
• Reproduced consistently across both GUID and Default-<guid> env-id formats

Workaround

None found for list_connections/invoke_operation specifically. get_flow/get_flow_context still work and surface a flow's connection references, so we're using those instead.

[DSerrano-AI]

Confirmed this is still present in v2.5.0 — tested live against an Advent tenant Default-<tenantId> environment for all four surfaces: list_connections, list_connectors, get_connector, and invoke_operation.

Root cause

getConnections, listConnectors, getConnector, and the connector-lookup step inside invokeOperation (all in plugins/power-automate/server/mcp.mjs) call this.ppapiRequest(...) directly instead of this.ppapiRequestWithFallback(...) — the helper #284/#284-family already added to catch ENOTFOUND/FETCH_FAILED on the per-environment PPAPI hostname and fall back to a working API. getFlow, runFlow, listDesktopFlows, etc. already route through the fallback; these four never got wired in, which is exactly why they still ENOTFOUND on Default-<tenantId>-style environments while flow operations work fine.

Fix, part 1 — invokeOperation / listConnectors / getConnector

All three build a path under /powerautomate/apis/... on the per-env PPAPI host — the same namespace getFlow already uses successfully through the fallback. The fix is a straight swap:

// before
const base = this.ppapiBase(envId);
const url = `${base}/powerautomate/apis/${connectorName}${this.ppapiFlowQs({ $expand: "swagger" })}`;
const connector = await this.ppapiRequest("GET", url);

// after
const path = `/powerautomate/apis/${connectorName}${this.ppapiFlowQs({ $expand: "swagger" })}`;
const connector = await this.ppapiRequestWithFallback(envId, path, "GET");

Same change for listConnectors (path /powerautomate/apis) and the connector-fetch inside invokeOperation. Confirmed live: invoke_operation against shared_office365/OnFilePickerOpen returned real mailbox folders; list_connectors and get_connector returned real connector/operation data — all against the Default-<tenantId> environment that previously ENOTFOUND'd.

Fix, part 2 — getConnections (list_connections)

This one doesn't fit the same fallback: getConnections calls ppapiConnectionsUrl(envId, opts), which hits /connectivity/connections on the per-env PPAPI host — a different namespace than /powerautomate/..., so classicFlowRpRequest's regex (^\/powerautomate\// → Microsoft.ProcessSimple/environments/{envId}/...) doesn't apply and there's no classic Flow RP equivalent for connections.

The actual fix: on isPpapiDnsFailure, fall back to the tenant-level Power Platform API host instead of a per-environment one — same host/pattern as the officially documented List Connectors endpoint, just for the sibling connections resource (undocumented but confirmed working):

async getConnections(envId, opts) {
  const url = ppapiConnectionsUrl(envId, opts);
  try {
    const data = await this.connectivityRequest("GET", url);
    return data.value;
  } catch (err) {
    if (this.isPpapiDnsFailure(err)) {
      const baseUrl = this.config.cloudEndpoints.powerPlatformApiUrl; // https://api.powerplatform.com
      const params = new URLSearchParams({ "api-version": "2024-10-01", "$filter": `environment eq '${envId}'` });
      const url2 = `${baseUrl}/connectivity/environments/${envId}/connections?${params.toString()}`;
      const token = await this.auth.getAccessToken(this.config.cloudEndpoints.powerPlatformApiUrl);
      const data2 = await this.requestWithToken("GET", url2, token);
      const values = data2?.value ?? [];
      return opts?.connector ? values.filter((c) => c?.properties?.apiId?.endsWith(`/${opts.connector}`)) : values;
    }
    throw err;
  }
}

Confirmed live: returned the full connection list for the Default-<tenantId> environment (name, connector, status, owner, createdTime, etc.) — this environment previously failed with the malformed-hostname ENOTFOUND on every one of these four calls.

Happy to open a PR with this if useful — wanted to post the diagnosis + working fix here first in case it's faster for someone on the team to just land it directly.

[DSerrano-AI]

Follow-up with the actual root cause (my earlier comment here worked around the symptom for a few tools but missed the real bug, and left single-connection operations broken).

Real root cause: ppapiBaseUrl() drops the default hostname prefix for Default-<tenantId> environments

Confirmed by capturing the Network tab from make.powerautomate.com itself (Data → Connections) against a Default-<tenantId> environment and diffing the hostname it actually uses vs. what plugins/power-automate/server/mcp.mjs builds for the same environment:

• Browser (works): default<hex30>.<hex2>.environment.api.powerplatform.com
• flowagent (ENOTFOUND): <hex30>.<hex2>.environment.api.powerplatform.com

ppapiBaseUrl(envId, ...) strips the Default- marker off the environment ID before hashing it into the hostname, and never restores it — but the literal string default needs to be prepended to the hashed prefix specifically for Default-<tenantId> environments. Dropping it produces a syntactically valid but non-existent hostname → ENOTFOUND.

One-line fix:

function ppapiBaseUrl(envId, templateOverride, suffixOverride) {
  const isDefaultEnv = /^Default-/i.test(envId);
  const rawId = envId.replace(/^Default-/i, "");
  const hex = rawId.replace(/-/g, "");
  const prefix = (isDefaultEnv ? "default" : "") + hex.slice(0, 30);
  const shard = hex.slice(30, 32);
  // ...rest unchanged

This single change is enough — I tested it against a real Default-<tenantId> environment and every previously-broken tool now works with no fallback plumbing needed at all: list_connections, list_connectors, get_connector, invoke_operation, get_operation_details, and — importantly — the single-connection family that my earlier fallback-based workaround could not cover: test_connection, fix_connection, pick_or_create_connection, delete_connection, connection permissions. Verified with a real write round-trip (created a live connection via pick_or_create_connection, confirmed Connected, then delete_connection cleanly removed it — no orphaned state).

This makes the ppapiRequestWithFallback DNS-catch-and-retry mechanism from #284/v2.1.0 unnecessary for Default- environments specifically — it was working around a hostname construction bug, not an actual DNS provisioning gap. It's presumably still useful for whatever other DNS-provisioning cases it was originally written for, just not this one.

Bonus unrelated bug found while re-testing: search_operations ignores its own filters

Not part of #333, but found in the same session, same file. The search_operations MCP tool handler builds:

const opts = {};
if (query) opts.searchText = query;
if (connector) opts.operationGroupName = connector;

but FlowClient.searchOperations(envId, opts) reads opts.query / opts.connector — different property names — so both filters are silently undefined on every call, and the tool always returns the same handful of generic operations (Manually trigger a flow, Condition, etc.) regardless of query.

Fix: align searchOperations() to read opts.searchText / opts.operationGroupName (matching what the handler sends, and what the PPAPI request body expects):

if (opts?.searchText) body.searchText = opts.searchText;
if (opts?.operationGroupName) body.operationGroupName = opts.operationGroupName;

Confirmed: search_operations({connector: "shared_commondataserviceforapps", query: "list records"}) now correctly returns ListRecords / ListRecordsWithOrganization instead of unrelated triggers.

Happy to open a PR for both if that's useful — these are two tiny diffs.