PersistKeysToDbContext Causing Extended Startup Time?

[TheWrightDev]

Title basically says it all. The table exists, it has the key it's going to use ready any waiting, but when I launch it I can't actually get any kind of response (just ERR_CONNECTION_REFUSED) for ~30 seconds.

This works great, controllers become available within a second or two.

        builder.Services
            .AddDataProtection()
            .PersistKeysToFileSystem(new DirectoryInfo(Path.Combine(builder.Environment.ContentRootPath, "..\\keyShare")))
            .ProtectKeysWithAzureKeyVault(dataProtectionKeyUri, new DefaultAzureCredential())
            .SetApplicationName("App");

This take ~30 seconds, which when developing is a real pain to wait to check a change:

        builder.Services
            .AddDataProtection()
            .PersistKeysToDbContext<DataProtectionContext>()
            .ProtectKeysWithAzureKeyVault(dataProtectionKeyUri, new DefaultAzureCredential())
            .SetApplicationName("App");

Watching the memory I can see the moment the app becomes available:

Anyone have any insight what's causing such a long delay? I even tried making it its own DbContext that was completely empty except for the DataProtectionKeys, but no dice.

[TheWrightDev]

Here is an example of one of the long delays in the log.

[13:14:45 DBG] Reading data with key 'key-...', value '<key id="..." version="1"></key>'.
[13:14:45 DBG] Found key {...}.
[13:14:45 DBG] Considering key {...} with expiration date 2023-12-05 20:13:34Z as default key.
[13:14:45 DBG] Forwarded activator type request from Azure.Extensions.AspNetCore.DataProtection.Keys.AzureKeyVaultXmlDecryptor, Azure.Extensions.AspNetCore.DataProtection.Keys, Version=1.2.2.0, Culture=neutral, PublicKeyToken=92742159e12e44c8 to Azure.Extensions.AspNetCore.DataProtection.Keys.AzureKeyVaultXmlDecryptor, Azure.Extensions.AspNetCore.DataProtection.Keys, Culture=neutral
[13:15:09 DBG] Forwarded activator type request from Microsoft.AspNetCore.DataProtection.AuthenticatedEncryption.ConfigurationModel.AuthenticatedEncryptorDescriptorDeserializer, Microsoft.AspNetCore.DataProtection, Version=7.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60 to Microsoft.AspNetCore.DataProtection.AuthenticatedEncryption.ConfigurationModel.AuthenticatedEncryptorDescriptorDeserializer, Microsoft.AspNetCore.DataProtection, Culture=neutral
[13:15:09 DBG] Opening CNG algorithm 'AES' from provider 'null' with chaining mode CBC.
[13:15:09 DBG] Opening CNG algorithm 'SHA256' from provider 'null' with HMAC.
[13:15:09 DBG] Using key {...} as the default key.
[13:15:09 DBG] Key ring with default key {...} was loaded during application startup.
'TestApp.exe' (CoreCLR: clrhost): Loaded 'C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App\7.0.10\Microsoft.AspNetCore.StaticFiles.dll'. Skipped loading symbols. Module is optimized and the debugger option 'Just My Code' is enabled.
'TestApp.exe' (CoreCLR: clrhost): Loaded 'C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App\7.0.10\Microsoft.Extensions.FileProviders.Embedded.dll'. Skipped loading symbols. Module is optimized and the debugger option 'Just My Code' is enabled.
[13:15:09 DBG] Using 'GzipBufferedRequestBodyHandler' body compression strategy with level "Optimal".
[13:15:09 DBG] Starting BackgroundWorker.
[13:15:09 DBG] BackgroundWorker Started.

[HappyRashair]

I believe this is due DB context initialisation and requests during startup for the data protection key.
I have the same problem with custom SQL data protection store.
You can mitigate it by using in-memory cache as your data protection store or Azure Key Vault - it should be faster.