Blob container ProviderType does not fall back to default container configuration

[EngincanV]

Problem

When configuring a named blob container with only non-provider options, such as IsMultiTenant, the container loses access to the default provider configuration.

Example:

Configure<AbpBlobStoringOptions>(options =>
{
    options.Containers.ConfigureDefault(container =>
    {
        container.UseDatabase();
    });

    options.Containers.Configure<WorkspaceDataSourceBlobContainer>(container =>
    {
        container.IsMultiTenant = false;
    });
});

In this case, WorkspaceDataSourceBlobContainer is created as a specialized named container with the default container as its fallback. However, ProviderType is a direct auto-property on BlobContainerConfiguration, so it does not use the fallback configuration.

As a result, provider resolution fails with:

No BLOB Storage provider was used! At least one provider must be configured to be able to use the BLOB Storing System.

See: https://github.com/volosoft/volo/issues/22446

Expected Behavior

A named blob container should inherit ProviderType from the default container when it does not explicitly set its own provider type. (if it's null)

This should behave consistently with other configuration values that already fall back through _fallbackConfiguration.

Actual Behavior

Custom configuration values use fallback resolution, but ProviderType does not.

This means a container configured only for options like IsMultiTenant must also repeat the provider configuration, even when a default provider is already configured.

Suggested Fix

Update BlobContainerConfiguration.ProviderType to use the fallback configuration when the current container has no explicit provider type.

Suggested implementation:

private Type? _providerType;

public Type? ProviderType
{
    get => _providerType ?? _fallbackConfiguration?.ProviderType;
    set => _providerType = value;
}

[Copilot]

Pull request overview

This PR fixes blob provider resolution for named blob containers by ensuring BlobContainerConfiguration.ProviderType properly falls back to the default container’s configuration when it isn’t explicitly set on the named container.

Changes:

• Implemented fallback-aware ProviderType in BlobContainerConfiguration (mirroring existing fallback behavior of custom configuration values).
• Added a test container configuration (TestContainer3) that only sets non-provider options to validate fallback behavior.
• Extended the existing fallback test assertions to cover IsMultiTenant for the specialized container.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.

File	Description
framework/src/Volo.Abp.BlobStoring/Volo/Abp/BlobStoring/BlobContainerConfiguration.cs	Makes ProviderType resolve via _fallbackConfiguration when not explicitly set.
framework/test/Volo.Abp.BlobStoring.Tests/Volo/Abp/BlobStoring/AbpBlobStoringTestModule.cs	Configures TestContainer3 with only non-provider options to exercise the fallback path.
framework/test/Volo.Abp.BlobStoring.Tests/Volo/Abp/BlobStoring/AbpBlobStoringOptions_Tests.cs	Asserts ProviderType fallback works and verifies IsMultiTenant is applied for the named container.

[codecov]

Codecov Report

❌ Patch coverage is 19.11765% with 55 lines in your changes missing coverage. Please review.
✅ Project coverage is 49.36%. Comparing base (1a48fe2) to head (a249f2a).
⚠️ Report is 19 commits behind head on rel-10.4.

Files with missing lines	Patch %	Lines
...bp/BlobStoring/BlobContainerConfiguration_Tests.cs	0.00%	33 Missing ⚠️
...olo/Abp/BlobStoring/AbpBlobStoringOptions_Tests.cs	0.00%	8 Missing ⚠️
...p/BlobStoring/Fakes/AnotherFakeNamingNormalizer.cs	0.00%	6 Missing ⚠️
...Volo/Abp/BlobStoring/Fakes/FakeNamingNormalizer.cs	0.00%	6 Missing ⚠️
...Volo/Abp/BlobStoring/BlobContainerConfiguration.cs	87.50%	0 Missing and 1 partial ⚠️
...Volo/Abp/BlobStoring/BlobNormalizeNamingService.cs	66.66%	0 Missing and 1 partial ⚠️

Additional details and impacted files

@@             Coverage Diff              @@
##           rel-10.4   #25615      +/-   ##
============================================
- Coverage     49.38%   49.36%   -0.02%     
============================================
  Files          3671     3674       +3     
  Lines        123885   123944      +59     
  Branches       9470     9470              
============================================
+ Hits          61179    61184       +5     
- Misses        60885    60928      +43     
- Partials       1821     1832      +11     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[maliming]

Hi @EngincanV, pushed one more edge fix on top of your ProviderType change.

NamingNormalizers doesn't fall back. If the default has UseAzure() and a named container inherits the ProviderType (your fix) but has no normalizers of its own, the named container silently drops AzureBlobNamingNormalizer and feeds raw names to Azure. The added GetEffectiveNamingNormalizers() resolves the list through the fallback, but only when the container also inherits its ProviderType — so a container that switches provider (UseDatabase() / UseAws()) doesn't pick up the default's normalizers and leak Azure rules onto Database/Memory names.