[Bug] PPAPI hostname malformed during connection/save operations -- blocks Studio-connected-connector saves via FlowAgent

[bohara2000]

Plugin

power-automate

Plugin Version

2.5.0

Skill / Command

flowagent MCP tools (list_connections, pick_or_create_connection, get_connector, search_operations, get_operation_details, test_connection, invoke_operation, update_flow/edit_flow)

Bug Description

Any FlowAgent tool call that needs the Power Platform API (PPAPI) fails with a NetworkError because the environment ID is being incorrectly split when constructing the target hostname.

Example: for an environment ID like 11111111-2222-4333-8444-555555555566 (redacted, format-preserving example), the expected hostname is:
11111111222243338444555555555566.environment.api.powerplatform.com

but the actual hostname produced is malformed, with a stray . inserted a couple of characters before the end of the ID, e.g.:
111111112222433384445555555555.66.environment.api.powerplatform.com

This same "insert a dot near the end of the ID" pattern reproduced consistently against our real environment ID as well, producing an unresolvable ENOTFOUND host.

Steps to Reproduce

1. In an affected environment, call any of: list_connections, pick_or_create_connection, get_connector, search_operations, get_operation_details, test_connection, or invoke_operation (non-picker/real operation).
2. Observe failure.

Expected Behavior

Call succeeds and returns connection/connector/operation data with a correctly formed hostname.

Actual Behavior

Fails with a NetworkError: ENOTFOUND against a malformed hostname (environment ID mangled with a stray "." inserted near the end) instead of the correct <environment-id>.environment.api.powerplatform.com.

Troubleshooting already performed:

• Reconnecting the environment via resolve_environment / set_current_env does not fix it.
• Confirmed this is a client-side URL-construction bug in the plugin (not stale auth/session state) -- same malformed hostname reproduces consistently regardless of session state.

Downstream impact (more severe than the direct tool failures):
This same broken lookup is also hit server-side during update_flow/edit_flow saves whenever the saved flow definition includes an action bound to a "connected" connector (e.g., Office 365 Outlook, Approvals -- SharePoint's own connection appears exempt/cached and saves fine). The platform requires a host.connectionReferenceName field on those actions to save at all, then fails to verify it via the same broken lookup, rejecting the save with:

"connection reference could not be found for the operation"

This occurs regardless of action name, whether the action is new or pre-existing, and regardless of edit size -- reproduced down to a single-field change deep inside an unrelated Switch action.

What still works (for reference):

• list_flows, get_flow, set_current_flow -- read operations, unaffected.
• resolve_entity/invoke_operation for picker lookups -- work, but silently return not-found/connection_missing on real failures instead of raising an error (flagging this as a secondary issue -- a bare not-found from resolve_entity shouldn't be trusted as ground truth).
• publish_flow/disable_flow -- starting/stopping a flow does not re-validate connections the same way and works fine even for flows containing connected-connector actions.

Current workaround:
None client-side. Flows touching Outlook/Approvals/other connected-connector actions must be built or edited directly in Power Automate Studio, whose own save path is unaffected by this bug.

Relevant Logs / Screenshots

NetworkError: ENOTFOUND (hostname: .environment.api.powerplatform.com)
"connection reference could not be found for the operation"

Environment

• OS: Windows 11 Enterprise (10.0.26200)
• Claude Code version: 2.1.228
• PAC CLI version: 2.9.3+ga17df1d

---

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

[radioblazer]

The latest fixes merged in from #393 address this - please raise if you continue to encounter.