Getting an error in the designer - the old issue is back

[SergeiMou]

Severity

P1 - Critical (Blocking production)

Describe the Bug with repro steps

Designer again can't get function metadata.

When I click open in the designer, this is what I see in the developer tools:

With some of my logic apps designer is working, and with some it is not. What could be the cause? We had this issuer before 1415 it appeared for some time to be fixed and now it is back again.

What type of Logic App Is this happening in?

Standard (VSCode)

Are you experiencing a regression?

No response

Which operating system are you using?

Windows

Did you refer to the TSG before filing this issue? https://aka.ms/lauxtsg

Yes

Workflow JSON

Screenshots or Videos

No response

Environment

Edge, 5.185.9, 5.185.10

Additional context

No response

[SergeiMou]

Hi @Eric-B-Wu I found the problem. In the local.settings.json file, there is the property "ProjectDirectoryPath".

"ProjectDirectoryPath": "c:\Users\MyUserName\source\repos\RepoName\Workflows"

If the path is wrong as it was in my case, the designer throws the NullReference exception with no details of what exactly it is not happy about.

Is this property really necessary? Wouldn't it be reasonable to assume that the very location of the local.setting.json is the ProjectDirectoryPath?

If for whatever reason this property is important, wouldn't it be better to use macros for the username in the path? Wouldn't it be also better to use the relative paths, instead of absolute? Otherwise, a simple moving of the project to another folder/repo will break it.

If you don't add the local.setting.json under source control (the default settings in .gitignore) it creates one sort of pain for dev teams, if you do add then it creates another issue that every developer has to adjust the hardcoded user names followed by the subsequent delight of dealing with conflict resolutions in git. The same goes to the workspace file where there are also hardcoded absolute paths.

I am not able to downgrade the severity; it is not the P1 of course but it needs to be addressed IMO as it makes VSCode very fragile.

[Eric-B-Wu]

@SergeiMou, thanks for providing this information, tagging @ccastrotrejo to see if there was any changes in Vscode here to change the ProjectDirectoryPath

[ccastrotrejo]

Hey @SergeiMou thanks for letting us know about this. So I have a couple of questions/comments on this.

• How was the property wrong? was it set to a different directory? was the setting as an empty string? was it set to another folder/repo/computer directory?
• We highly encourgae to not commit under source control the local.settings.json. That file usually host credential/keys that we rely on while auth the workflows and that might set a security concerns for your resources. Obviously, we don't have control over that, but as the local.settings.json aren't commited, we created the file again in case the customer cloned the repo or downloaded it from somewhere, when we start the designtime api.
• Whenever we start the design time api when opening the desigenr we update the local.settings.json to reflect the udpate on the projectPath, so I am quite curious what was the wrong path you your configuration had.

I will also bring it back to the team on what we can do about not relying on a setting/property on a json file

[SergeiMou]

Hi @ccastrotrejo

Answering your questions.
In my scenario, I was doing some re-org where I had to move the LA project to another repo. So... Created a new repo in Azure DevOps Cloned to my local disk Copied the code from the old folder to the new Deleted the old folder Opened the project from the new folder. Voila - designer throws an error as the path points to the old already deleted folder.

If LA extension goes to the local.setting.json for the ProjectLocation, wouldn't it reasonable to assume that the very location of the local.settings.json IS the ProjectLocation?

I do agree that teams have to be careful with putting local.settings under source control, but what are the other options - how do we keep local.settings in sync accros the team if not via source control? Emailing to each other with a comment like "don't forget to adjust the ProjectLocation"?

The same goes to the workspace file which also contains hardcoded usernames and direct paths and by default is in .gitignore. Interestingly, when you open the workspace file, VSCode automatically replaces the username which is kind of a good thing, but it creates another issue if the file is under source control. With the automatically adjusting username, you will sooner or later end up with having to resolve conflicts in GIT.

I think using relative paths and macros or env.vars like %USER% in the paths could help a lot. It will help us, and it will help you guys as well who have to deal almost every week with the "designer is broken again". Well, I don't the details of implementation, things very well might be not as simple as I see them. But hopefully I still provided some food for thoughts to the product group as it is really an issue.

Thank you, guys, for all the hard work!