Post

Direct Line App Service Extension Bot Connectivity Issues with Azure Deployment Slots

Introduction

If you’re working with an Azure Bot using the Direct Line App Service extension and deployment slots, you may encounter some unexpected connectivity issues. In this post, I’ll walk you through a recent problem we faced where one slot’s Direct Line configuration flags were always set to False, resulting in a frustrating 502 error. After troubleshooting, we identified the root cause and applied a simple configuration fix that restored connectivity. Here’s how we resolved it.

The Problem

We observed that when using production and testing deployment slots in Azure Web Apps, the bot started experiencing connectivity issues. Only one slot could function properly at a time. The active slot had the Direct Line configuration flags (IB/OB) set to True/True, while the inactive one showed False/False. When switching between slots, this behavior would toggle, causing one of the bots to consistently fail to connect, resulting in a 502 error.

Despite following the usual configuration practices, the problem persisted, so we needed to dive deeper into the issue.

Digging into the Root Cause

The issue boiled down to how the bot communicates with the App Service Extension. It uses named pipes for this, and the pipe name is generated using an environment variable called APPSETTING_WEBSITE_SITE_NAME, which is set by the App Service based on the site’s name.

However, here’s the tricky part: when using deployment slots, all slots share the same value for this environment variable. This overlap created a conflict, as both production and testing environments were using identical pipe names, which only allowed one connection at a time.

The Solution

To resolve this issue, we made a targeted configuration change that ensured each slot had its own unique pipe name. Here’s the step-by-step breakdown of what we did:

1. Create the ApplicationHost.xdt File

We created a configuration file called ApplicationHost.xdt and placed it in the c:\home\site\ directory. This file would allow us to override the environment variable specifically for the test slot.

2. Add the Slot-Specific Configuration

In the ApplicationHost.xdt file, we added the following configuration to ensure that the test slot had its own unique value for APPSETTING_WEBSITE_SITE_NAME:

1
2
3
4
5
6
7
8
9
10
11
<?xml version="1.0"?>
<configuration xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform">
   <system.webServer>
       <runtime xdt:Transform="InsertIfMissing">
           <environmentVariables xdt:Transform="InsertIfMissing">
               <add name="APPSETTING_WEBSITE_SITE_NAME" value="bot-app-test"
                   xdt:Locator="Match(name)" xdt:Transform="InsertIfMissing" />
           </environmentVariables>
       </runtime>
   </system.webServer>
</configuration>

3. Restart the Sites

Once the configuration was in place, we restarted both the production and test environments to apply the changes.

4. Verify the Fix

After the restart, we verified that both inbound and outbound connections were now functioning correctly in both environments. We ran several tests on the bot, and everything worked as expected with no further connectivity issues.

Key Takeaways

This scenario highlights a key consideration when using deployment slots in Azure: environment variables can be shared across slots, which may lead to conflicts—especially when components like named pipes depend on unique values. By overriding the APPSETTING_WEBSITE_SITE_NAME variable for the test slot, we were able to eliminate this conflict and restore proper functionality.

When dealing with similar scenarios, always check whether shared environment variables might be the source of conflicts between slots.

Conclusion

If you’re using Azure deployment slots and encounter issues with bot connectivity, double-check how your environment variables are being handled across slots. In our case, a simple configuration change resolved what seemed like a complex issue.

Have any similar experiences or tips? Feel free to share them in the comments below! And as always, happy coding!


This post is licensed under CC BY 4.0 by the author.