自定义BotState服务接入Cosmos DB后报‘Resource Not Found’错误排查
I've migrated my bot from the deprecated default BotState service to Azure Cosmos DB storage, using a custom module registered in the Conversation Container's Application_Start method:
public class CustomBotStateServiceModule : Module { protected override void Load(ContainerBuilder builder) { var stateStore = new DocumentDbBotDataStore( new Uri(ConfigurationManager.AppSettings.Get("EndpointUri")), ConfigurationManager.AppSettings.Get("PrimaryKey"), ConfigurationManager.AppSettings.Get("DatabaseId"), "BotState"); builder.Register(c => stateStore) .Keyed<IBotDataStore<BotData>>(AzureModule.Key_DataStore) .AsSelf() .SingleInstance(); builder.Register(c => new CachingBotDataStore(stateStore, CachingBotDataStoreConsistencyPolicy.ETagBasedConsistency)) .As<IBotDataStore<BotData>>() .AsSelf() .InstancePerLifetimeScope(); } }
When testing locally with the Bot Channel Emulator, I see multiple "Resource Not Found" errors in the Visual Studio debug output the first time BotState is accessed. The Cosmos DB collection BotState gets created correctly, and the bot works fine otherwise. I need to understand the root cause and if there's any associated risk.
Root Cause
This is expected behavior from the Bot Framework SDK's DocumentDbBotDataStore implementation:
- On first access, the SDK checks if the target database and
BotStatecollection exist in your Cosmos DB account. - If the resources don't exist yet, the SDK automatically creates them—but the initial check requests will return a "Resource Not Found" response before the creation completes.
- The
CachingBotDataStorewrapper adds an extra layer of initialization logic, which can trigger multiple check requests during the first load, leading to repeated error logs. - Since your Cosmos DB account already has other databases and collections, the SDK's initial lookup for the specific bot database/collection will fail until those resources are provisioned.
Risk Assessment
- No functional impact: This error is purely debug log noise from the SDK's internal provisioning flow. Once the database/collection is created, all subsequent BotState operations work as expected.
- Minor cost consideration: The extra check requests add a small number of RU (Request Unit) charges to your Cosmos DB bill, but this is negligible since it only happens on bot startup or first BotState access.
- Red flag for persistent errors: If you start seeing this error consistently after the first load, that indicates a real issue (e.g., incorrect endpoint/primary key, deleted resources, or permission misconfigurations). But your scenario aligns with the normal one-time provisioning flow.
Optional Fixes to Eliminate the Error
Pre-create the resources manually:
Log into the Azure Portal, navigate to your Cosmos DB account, and create the database matching yourDatabaseIdapp setting, plus a collection namedBotState. This way, the SDK's initial checks will find existing resources and skip the creation flow.Filter debug output:
In Visual Studio, use the debug output filter to hide "Resource Not Found" messages (you can filter by the error text or log level). This keeps your debug log clean without changing any code.Adjust logging configuration:
If you're using a logging framework with the Bot SDK, lower the log level for Cosmos DB-related events to suppress these informational error messages.
内容的提问来源于stack exchange,提问作者Markkknk

