You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
To work with Logic Apps (Standard) both locally from Visual Studio Code and from Azure, the Managed API Connections need to be parameterized because Managed API Connections require an access token when running locally while using managed identity when running in Azure.
When you first configure a Managed API Connection in the Logic Apps (Standard) Designer in Visual Studio Code, the extension adds a Managed API Connection to connections.json and stores the access token for that Connection in local.settings.json. If you modify an existing Connection on an Action an access token is recreated. This access token is valid for 7 days.
Currently, the only way to renew that access token using the Logic Apps (Standard) extension is to tweak the Managed API Connection for an Action from the Designer. This causes the extension to renew the access token, but the access token is not renewed when the Logic App is debugged locally or when a Workflow using the Managed API Connection is saved.
The Logic Apps (Standard) extension should be checking and renewing the access token if it has expired when a Workflow is opened or saved in the Designer or when the Workflow is run from the Visual Studio Code debugger.
The workaround I have been using is a PowerShell script that runs during debugging to use the Azure CLI to POST to the listConnectionKeys REST endpoint for each Managed API Connection's ID. The ID is built from the parameterized Managed API Connection in connections.json, paramters.json, and local.settings.json.
It would be great if this functionality were built into the Logic Apps (Standard) extension.
This issue occurs with any Managed API Connection because of the difference in how Managed API Connections are used locally versus in Azure. It is not unique to any particular Managed API Connection type.
The text was updated successfully, but these errors were encountered:
Describe the Bug with repro steps
To work with Logic Apps (Standard) both locally from Visual Studio Code and from Azure, the Managed API Connections need to be parameterized because Managed API Connections require an access token when running locally while using managed identity when running in Azure.
When you first configure a Managed API Connection in the Logic Apps (Standard) Designer in Visual Studio Code, the extension adds a Managed API Connection to
connections.json
and stores the access token for that Connection inlocal.settings.json
. If you modify an existing Connection on an Action an access token is recreated. This access token is valid for 7 days.Currently, the only way to renew that access token using the Logic Apps (Standard) extension is to tweak the Managed API Connection for an Action from the Designer. This causes the extension to renew the access token, but the access token is not renewed when the Logic App is debugged locally or when a Workflow using the Managed API Connection is saved.
The Logic Apps (Standard) extension should be checking and renewing the access token if it has expired when a Workflow is opened or saved in the Designer or when the Workflow is run from the Visual Studio Code debugger.
The workaround I have been using is a PowerShell script that runs during debugging to use the Azure CLI to
POST
to thelistConnectionKeys
REST endpoint for each Managed API Connection's ID. The ID is built from the parameterized Managed API Connection inconnections.json
,paramters.json
, andlocal.settings.json
.It would be great if this functionality were built into the Logic Apps (Standard) extension.
What type of Logic App Is this happening in?
Standard (VSCode)
Are you using new designer or old designer
New Designer
Did you refer to the TSG before filing this issue? https://aka.ms/lauxtsg
Yes
Workflow JSON
No response
Screenshots or Videos
No response
Browser
Not really applicable from VSCode, but I use Edge
Additional context
This issue occurs with any Managed API Connection because of the difference in how Managed API Connections are used locally versus in Azure. It is not unique to any particular Managed API Connection type.
The text was updated successfully, but these errors were encountered: