[Bug] get_flow_context/updateFlow misdetect solution membership when a flow has two valid PPAPI IDs; new autoMergeConnectionRefs also blocks writes (blocks verifying #360's fix)

[LucianoModest0]

Plugin

power-automate

Plugin Version

3.0.1

Skill / Command

N/A (MCP tools: get_flow_context, edit_flow, update_flow)

Bug Description

While trying to verify whether v3.0.1 (PR #393, closing #360) resolves the "should not have the property 'authentication'" save error for Dataverse-solution flows, we hit two other, earlier blocking issues that prevent the request from ever reaching the #360 fix code (stripInjectedAuthentication).

1. get_flow_context misdetects solution membership because a flow can be addressed by two different, equally valid PPAPI IDs.

The flow is a PowerApp-V2-triggered cloud flow, member of an unmanaged Dataverse solution, created via create_flow on 2026-08-07. We discovered the Power Automate portal's own flow-details URL uses a different GUID for this flow than the ID returned by list_flows/run-history calls for the exact same flow. Both IDs resolve successfully via get_flow and report the identical properties.workflowEntityId, properties.createdTime, and properties.lastModifiedTime (down to the second) — conclusively the same underlying Dataverse record, not a duplicate/copy.

• get_flow_context(idA) → {"inSolution": true, "workflowId": "<realWorkflowId>", "warning": null}, where idA happens to equal the flow's Dataverse workflowidunique field.
• get_flow_context(idB) → {"inSolution": false, "warning": "workflow-not-found"}, for the same flow, where idB is the ID this flow is otherwise addressed by everywhere else (portal run history, list_flows, etc.).

Reading the bundled source (inlined in server/mcp.mjs), getFlowContext() looks up workflows(<flowId>) by primary key first, then falls back to a workflowidunique eq <flowId> filter query — so it only succeeds when called with the ID that happens to equal workflowidunique. Since updateFlow() only takes the safer direct-Dataverse-clientdata write path when ctx.inSolution && ctx.workflowId && !ctx.warning, a flow addressed by its non-workflowidunique ID always falls through to the more fragile PPAPI write path — plausibly a meaningful contributor to the flakiness reported across #360/#392/#287/#342/#346 for solution flows generally, not just an isolated quirk of our environment.

2. New autoMergeConnectionRefs step (added since 2.0.0) blocks edit_flow even when a valid Connected connection exists.

The flow's actions use the legacy embedded/dynamic-token authentication pattern (host.connectionName + a raw authentication token derived from the trigger's APIM headers) rather than registered connectionReferences — the exact shape #360 targets. Calling edit_flow (even a no-op edit touching an unrelated action) fails with:

No connected connection found for shared_sharepointonline. Create one with: create-connection --env=<envId> --connector=shared_sharepointonline

This is surprising because a direct list_connections --connector=shared_sharepointonline call, run immediately after the failure, returns 3 connections for that exact connector, all with status Connected.

updateFlow() unconditionally runs autoMergeConnectionRefs(envId, flowId, body) before stripInjectedAuthentication(body). autoMergeConnectionRefs computes "needed" connector keys via extractConnectorKeysFromDefinition(definition), which collects the raw action.inputs.host.connectionName string from every action — including Power Automate's own multi-use suffixes (a flow using the same connector twice gets shared_sharepointonline and shared_sharepointonline-1 as two distinct "connector keys"). Our hypothesis (not fully isolated — flagging as the most likely lead, not a confirmed root cause) is that this raw key, or a mismatch between the internal listConnections filter used here and the one used by the public list_connections tool, is why the auto-merge step reports zero connections for a connector that demonstrably has three.

Because edit_flow's public schema has no option to disable this auto-merge (no autoResolveConnectionRefs parameter exposed, even though the internal opts.autoResolveConnectionRefs !== false check implies one should exist), there is currently no way to work around this and reach the #360 fix code for this class of flow. We cannot yet confirm or deny whether v3.0.1 actually resolves #360 for flows in this specific state (solution-member, PowerApp-V2 trigger, legacy embedded/dynamic authentication, no registered connectionReferences, two valid PPAPI IDs).

Steps to Reproduce

Dual-ID / get_flow_context:

1. Take a cloud flow that is a member of a Dataverse solution and has been open/saved in the Power Automate portal's Designer at least once.
2. Note the flow ID in the portal's own URL (.../flows/<id>/details).
3. Separately, get the same flow's ID as returned by list_flows or a prior get_run_history call for it.
4. If these two IDs differ, call get_flow_context with each one and compare results.

autoMergeConnectionRefs:

1. Have a PowerApp-V2-triggered cloud flow that is a member of an unmanaged Dataverse solution, with multiple OpenApiConnection actions using the same connector twice (so the definition contains both connectionName: "shared_X" and connectionName: "shared_X-1"), authenticated via the legacy embedded/dynamic-token pattern (no registered connectionReferences).
2. Confirm via list_connections --connector=shared_X that at least one Connected connection exists for that connector.
3. Call edit_flow with any single, unrelated operation (e.g. set a Response action's statusCode to its current value).
4. Observe the error.

Expected Behavior

• get_flow_context should correctly detect solution membership regardless of which of the flow's two valid PPAPI IDs is passed in, since both indisputably resolve to the same flow (confirmed by identical properties.workflowEntityId/createdTime/lastModifiedTime from get_flow).
• edit_flow should either (a) successfully auto-merge/resolve the connection reference using an existing Connected connection, or (b) proceed to the [power-automate][Bug] update_flow/preview_update cannot save any connector action with 'authentication' in a Dataverse-solution flow #360 fix (stripInjectedAuthentication) without requiring a pre-existing registered connectionReferences entry when the flow doesn't declare connectionRefs and the actions still use legacy embedded authentication.

Actual Behavior

get_flow_context(idA) -> {"inSolution": true, "workflowId": "<realWorkflowId>", "warning": null}
get_flow_context(idB) -> {"inSolution": false, "warning": "workflow-not-found"}
(same flow; idA == workflowidunique, idB is the ID returned elsewhere for this flow)

edit_flow(idB, <no-op operation>):
No connected connection found for shared_sharepointonline. Create one with: create-connection --env=<envId> --connector=shared_sharepointonline

even though list_connections for the same connector, in the same environment, returns 3 Connected connections.

Relevant Logs / Screenshots

Prior v2.0.0 test, distinct issue, kept for context on #360:
{"error":{"code":"XrmApiRequestFailed","message":"Request to XRM API failed with error: 'Message: Flow client error returned with status code \"BadRequest\" and details \"{\"error\":{\"code\":\"InvalidOpenApiFlow\",\"message\":\"Flow save failed with code 'WorkflowRunActionInputsInvalidProperty' and message 'The 'inputs' of workflow run action '<ActionName>' of type 'OpenApiConnection' should not have the property 'authentication'.'.\"}}\".\nCode: 0x80060467\nInnerError: '.","extendedData":{...}}}}

v3.0.1 new blocking error (this report):
No connected connection found for shared_sharepointonline. Create one with: create-connection --env=<envId> --connector=shared_sharepointonline

Relevant source excerpt (server/mcp.mjs, function extractConnectorKeysFromDefinition):

function extractConnectorKeysFromDefinition(definition) {
  const keys = new Set();
  function scanActions(actions) {
    for (const action of Object.values(actions)) {
      const connName = action?.inputs?.host?.connectionName;
      if (connName) keys.add(connName);
      // ...recurses into nested containers...
    }
  }
  scanActions(definition.actions);
  return keys;
}

No normalization strips the -1/-2 multi-use suffix Power Automate itself adds to connectionName before this is used as a connector identifier downstream in autoMergeConnectionRefs.

Environment

• OS: Windows 11 Pro 10.0.26200
• Claude Code version: 2.1.214
• PAC CLI: 2.9.3+ga17df1d (.NET 10.0.10)
• Node.js: v24.18.0

---

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