4.4.1
I have a bot file that I want to use for any local bot running on port 3978:
{
"name": "3978",
"description": "",
"services": [
{
"type": "endpoint",
"appId": "",
"appPassword": "",
"endpoint": "http://localhost:3978/api/messages",
"id": "1",
"name": "Unauthenticated"
},
{
"type": "endpoint",
"appId": "<GUID>",
"appPassword": "<password>",
"endpoint": "http://localhost:3978/api/messages",
"id": "2",
"name": "GitHubProfileBot"
}
],
"padlock": "",
"version": "2.0",
"path": "C:\\Dev\\3978.bot",
"overrides": null
}
This shows up just fine in the bot explorer panel, and I can open up both endpoints simultaneously by clicking "Open in Emulator" in the context menu:

However, you are supposed to be able to open an endpoint by just clicking on it in the endpoint list. This doesn't work if the endpoint has the same URL as an endpoint that's already open. It seems like the behavior for clicking an endpoint from the list involves checking the endpoint URL to see if it matches any of the open tabs, and then switching to that tab if one is found. It doesn't realize that the tab it's switching to is not the same endpoint as the one I clicked.
Steps to reproduce the behavior:
The Emulator should recognize an endpoint by its ID (or perhaps the combination of all its properties) instead of its URL, and it should open an endpoint when you click on it even if another endpoint with the same URL is already open. While it may seem like this isn't useful because you can't run multiple bots on the same port, the Emulator does allow you to open multiple tabs with the same URL through the context menu, and that indicates that this bug is not by design.
[bug]
This is "works as designed". Single click on an endpoint in the list focuses that chat if it is already open or creates a new chat otherwise. Right click and choose "Open in Emulator" will always open open a new chat. The code that is responsible for this behavior is explicit. Notice that true is passed in as the value for focusExistingChatIfAvailable
This requirement was discussed with @mewa1024 back when it was implemented. This behavior is similar to how Mac manages open applications in the icon bar. Clicking on an icon focuses that app or opens it if it is not already running while right clicking presents a context menu that allows the explicit opening of a new instance.
@cwhitten - Please confirm we can close this as WAD.
@denscollo - Please follow up with Chris to determine the appropriate action for this ticket.
@justinwilaby - I just want to make sure you're not misunderstanding this issue.
Single click on an endpoint in the list focuses that chat if it is already open or creates a new chat otherwise. Right click and choose "Open in Emulator" will always open open a new chat.
I understand that clicking an endpoint should only open a new tab if that endpoint isn't already open. It sounds like you think my issue is that I think clicking an endpoint should always open a new tab. This is not my issue.
My issue is that clicking an endpoint that is _not_ open in any tab does not open a new tab, given that there's already a tab open that Emulator _mistakes_ for the tab that you clicked. I have two _different_ endpoints, I click one and it opens, and then I click the other one and it _should_ open but it doesn't. As you said, the Emulator should open a new chat if the endpoint isn't already open in one.
Emulator uses the app ID and password for an endpoint, so if two endpoints with the same URL have a different app ID and password then they need to be treated as two different endpoints.
@v-kydela - Thank you for the clarification. I am able to repro this when the endpoints share the same ID.
In this case, the defect is due to a misconfigured bot file and duplicates #990 which is still pending discussion.
@cwhitten - can you please provide guidance on a definitive action here? I'm happy to solve this by contributing a validation schema to botframework-config and then using those bits in the Emulator.
@justinwilaby - I did see #990. I believe the two issues are related but not the same.
Are you sure the only time a bot file would have two endpoints with the same URL is if the bot file is misconfigured? I have a very real use case here. I want to be able to use one bot file to connect to localhost:3978 which all my bots use, and be able to authenticate using any of my Microsoft app credentials.
~@v-kydela as I understand it, the .bot file is intended to house information for one bot only and it seems you may be using the mechanism in a way that wasn't intended. I believe the support we offer today is that if you have different services all happening to use the same local endpoint, it would still require different .bot files for each.~
Upon re-reading your initial issue @v-kydela I understand the situation more clearly. One .bot, multiple services of endpoint type with their endpoint value being the same.
I can confirm that 2 endpoints within the same botfile with the same endpoint value will repro this.
This issue is a bot more complex and warrants discussion. The schema for the IConnectedService shows the id field as optional and no enforcement is made to ensure unique ids for services within a botfile. This fact lead the Emulator to register endpoints via the endpoint field which works for deployed bots but breaks for local bots given @v-kydela 's use case.
The question is then: "how do we guarantee a unique identifier for services within a botfile?"
id field as required, read only and unique. Then validate this on all botfiles being opened in the Emulator. This affords us to register the endpoints by id instead of by theendpoint field since we can now rely on the ids being unique. I am for solving #990 since it would address the side-effects of not being able to rely on unique ids.
Looks like the name field has no guarantee of uniqueness either, which may be a problem since the user wouldn't be able to tell them apart in the sidebar
During standup last week, we decided that the root cause of the issue should be fixed, which is that the bot file -- msbot -- needs to generate a stable, unique id for endpoint services so that they can be reliably differentiated between by the Emulator.
@cwhitten I'd still like to investigate this one as I ran into the scenario on 4.5.x.
It sounds like the proper solution might be using an endpoint URL and ConnectedService.id combination, or basically anything that doesn't use _just_ the endpoint URL to decide which configuration to use.
Edit:
Using a combination of endpoint URL and AppId may solve the issue in an acceptable manner.
This ticket has been fixed here
https://github.com/microsoft/BotFramework-Emulator/blob/master/packages/app/main/src/commands/botCommands.ts#L225
Irrespective of having multiple endpoints having the same URL they are tracked with a unique ID generated inside Emulator.
Most helpful comment
I can confirm that 2 endpoints within the same botfile with the same
endpointvalue will repro this.This issue is a bot more complex and warrants discussion. The schema for the IConnectedService shows the
idfield as optional and no enforcement is made to ensure unique ids for services within a botfile. This fact lead the Emulator to register endpoints via theendpointfield which works for deployed bots but breaks for local bots given @v-kydela 's use case.The question is then: "how do we guarantee a unique identifier for services within a botfile?"
idfield as required, read only and unique. Then validate this on all botfiles being opened in the Emulator. This affords us to register the endpoints byidinstead of by theendpointfield since we can now rely on the ids being unique.I am for solving #990 since it would address the side-effects of not being able to rely on unique ids.