Botframework-sdk: Creating of conversation with user from another region is failed

[WhiteCyClop]

Version

4.10.3

Describe the bug

When I try to start a conversation with a user via BotFrameworkAdapter.CreateConversationAsync() - I get an "Operation returned an invalid status code 'Forbidden'" error if the user has a ServiceUrl other than "https://smba.trafficmanager.net/emea/". For example, several users have a ServiceUrl equal to "https://smba.trafficmanager.net/fr/" and for them I get an error while creating a conversation. I am using the AppCredentials.TrustServiceUrl() method before creating the conversation, but that does not help to avoid the error.

Expected behavior

I want to create a conversation regardless of the user's region

[jwiley84]

Hi @WhiteCyClop Can you explain a bit more about the bot? What's the region the bot is hosted in?

[WhiteCyClop]

Hello! Location of my App Service at Azure is "UK South", location of the Resource Group is "West Europe". Most of users (nearly 800) have Service Url equaled to "https://smba.trafficmanager.net/emea/", but some users (~10) some times have "https://smba.trafficmanager.net/fr/" - the list of these users changes from time to time

[WhiteCyClop]

@jwiley84 is there any information on this issue?

[jwiley84]

Hi @WhiteCyClop I"m getting closer to tracking down an answer, but one question: is this a skype bot or a teams bot? If it's Teams, then the service URL should be the same for all users in a single tenant.

[WhiteCyClop]

Hi @jwiley84 , this is a teams bot and all users in single tenant

[adamist521]

Having same issue

same situation

this is a teams bot and all users in single tenant

Following issue seem to be discussing on the same issue.
https://github.com/microsoft/botbuilder-js/issues/3280

[WhiteCyClop]

Yes, it's a very similar situation indeed. I also get wrong service url after users response via Action.Submit in adaptive card that I send to them on a some schedule

[matthiasdilger]

@WhiteCyClop It seems that Action.Submit activities are sometimes "routed" via other service urls. /apac instead of /in, /fr instead of /emea, /jp instead of /apac etc. You can use methods like .updateActivity on these activities but the user does not exist on these urls. My workaround is to lookup the url from the bot installation event and use that instead. If your users are all on the same tenant you could simply hard code it.

[WhiteCyClop]

@matthiasdilger Thanks for the advice. I am planning to add try-catch and if this error occurs try hardcoded posting. But of course it would be great to have a complete solution of this problem

[thschuetze]

Hi, we are experiencing the same issue with a live customer.
BotFramework C# SDK version 4.7.2, but it seems to be unrelated to the version.

All our current Teams users should have the /emea/ url, but sometimes messages from random users come with the /fr/ url. Our bot is able to respond to the /fr/ messages, but we cannot create a new conversation with that wrong serviceUrl.

This is especially annoying because we use pro-active messages for urgent notifications to our users and at the moment they can't trust this feature and have to regularly check if they have new tasks that need their attention.

We can implement a work around for this, but at the moment we do not store the "correct" serviceUrl for our users. We only update the "last used" serviceUrl for each user and we don't know which one is the correct one.
Since we don't know what causes this, even the users first ever message might come with the wrong serviceUrl?

How do you guys identify the "fallback" serviceUrl to use in case the most recent one fails?

[matthiasdilger]

How do you guys identify the "fallback" serviceUrl to use in case the most recent one fails?

Hi @thschuetze the correct serviceUrl is only unique per tenant, not per user. If you don't have my different tenants in your app, you could manually maintain a table that maps tenants to the correct serviceUrl. If you do have a lot of different tenants you would need to either store the serviceUrl from the installation event (which seems to be always correct) or set the serviceUrl per tenant when communication is successful and look it up from there if communication fails.

Either way, you would need to maintain some sort of table so your app can look up the right "fallback" serviceUrl.

[nilsmehlhorn]

Storing the serviceUrl seems like an unnecessary workaround that also won't really work if you already have an app deployed. In that case you can't store the serviceUrl upon installation because users will already have the app installed. IMHO, the bot framework should always provide the proper serviceUrl or allow for creating a new conversation without it. I don't really get why the bot framework can't figure the serviceUrl out on its own based on the user's region.

Also, this seems to occur only recently. In our case, we were creating a new direct conversation from a message extension action command invoked in a channel or group chat. Starting around 2021-02-09, this now no longer works. We've worked around it by replacing the direct conversation (which was a confirmation for the message extension interaction) with an "empty" task module that only displays a message.

[jwiley84]

Thank you for your patience. Just waiting for an update from the above linked issue to see if it is related to this one.

[jwiley84]

It appears something was quietly fixed in the backend. Can you please attempt to repro your issue and see if it's still occurring?

[WhiteCyClop]

Checked it, there are no any errors at the moment.