Functions bots do not work when running locally (LUIS, QNA and other settings are not properly received)

[Virtual-Josh]

Describe the bug

Dotnet function bots throw an invalid LUIS subscription key error when trying to call LUIS

Version

Version: 2.0.0-nightly.243234.8264ac4
Electron: 8.2.4
Chrome: 80.0.3987.165
NodeJS: 12.13.0
V8: 8.0.426.27-electron.0

Browser

• Electron distribution
• Chrome
• Safari
• Firefox
• Edge

OS

• macOS
• Windows
• Ubuntu

To Reproduce

Steps to reproduce the behavior:
Updated

1. create empty dotnet bot
2. add and wire up echo intent
3. create provisioning profile and publish bot (step that was missing)
4. start bot
5. send intent message

Expected behavior

The call should go through

Screenshots

Additional context

The fix for this issue is probably similar to the fix for this issue since the errors are fairly similar.

[sgellock]

Shiproom - I am not able to repo this with the currently nightly. let's get a second opinion to see if we an repro the issue

[sgellock]

Shiproom - @benbrown will try and repro this a.m.

[Virtual-Josh]

ahh slightly modified set of setps

1. create empty dotnet bot
2. add and wire up echo intent
3. create provisioning profile and publish bot (step that was missing)
4. start bot
5. send intent message

This repos with today's build.

[Virtual-Josh]

As one additional piece, if you test the bot in azure the bot doesn't respond if you try to invoke LUIS, but does respond if it stays local. The weird thing is web chat doesn't produce the invalid luis subscription error that happens locally.

[benbrown]

I CAN reproduce this.

[benbrown]

When running locally, Composer passes sensitive settings like the LUIS endpoint key, QNA endpoint key, and Microsoft App Password via command line arguments to the runtime, for example: (pseudocode) dotnet start mybot.csproj --luis:endpoint=123

see code here:

BotFramework-Composer/extensions/localPublish/src/index.ts

Line 409 in 0c914b2

spawnProcess = spawn(startCommand, args, {

This works fine for normal web apps that accept these parameters and use them.

However, the func runtime does NOT pass these parameters into the running app, and thus they are missing and the app errors.

The proposed workaround is that developers using the func runtime locally create an appsettings.development.json file with these values.

[Virtual-Josh]

For an additional piece of context, a similar issue is happening for Node function bots. The error presented is different, but initial investigation would suggest it's ultimately pointing towards the same issue of the app settings being inaccurate.

[peterinnesmsft]

@sgellock @tracyboehrer per request, updating issue with investigation findings. I have identified a potential solution to supporting this in Composer. @benbrown @joshgummersall please review the below:

---

The Azure Functions runtime by default makes use of environment variables for the purposes of supplying configuration to the application. For local development using the Azure Functions CLI, local.settings.json is provided as a means of providing environment variables when running locally.

The CLI provides an API, func settings, with operations for adding and removing environment variables to this file without having to manually manipulate it.

Following the repro steps above, I was able to successfully get my bot running by issuing the following commands manually when in the same directory containing local.settings.json:

PS C:\Users\peinnes\source\repos\Empty\Empty> func settings add MicrosoftAppPassword ___
PS C:\Users\peinnes\source\repos\Empty\Empty> func settings add luis:endpointKey ___
PS C:\Users\peinnes\source\repos\Empty\Empty> func settings add qna:endpointKey ___
PS C:\Users\peinnes\source\repos\Empty\Empty> func settings add SkillHostEndpoint http://127.0.0.1:3980/api/skills

For sanity, here is web chat showing successful dialog for .NET Functions in Composer:

...and here is JS Functions in Composer:

To that extent, making the assumption that it has access to the corresponding secrets, I believe that we can update the runtime extensions logic in Composer to simply invoke the func settings add API to register these settings in local.settings.json. This file is already scaffolded by the templates. Additionally, running add multiple times will override a setting if it is already specified.

Finally, as last sanity check, per the Azure Functions documentation, values in local.settings.json will only apply when being run locally - in other words, this should not clobber the contents of our appsettings.json values in a deployed context.

N.B.: For .NET, since the app runs from the context of the build output directory (/bin/Debug/netcoreapp3.1), the local.settings.json in the project root would need to be updated BEFORE executing dotnet build to ensure that the values are in place of the executing location.

[sgellock]

Shiproom - let's see what a PR would look like and assess for R13

[sgellock]

Shiproom - approved - functions with services is P0