Dependency Injection Error

[justinmiller62]

Dependency Injection Error Prevents Application Startup on macOS/Linux

Description

The application fails to start on macOS (and likely Linux) due to a dependency injection lifetime mismatch. A singleton service (ExtendedConfig) is attempting to consume a scoped service (ISettingsProcessor), which violates ASP.NET Core's DI rules.

Environment

• OS: macOS (Darwin 24.4.0) - ARM64
• Docker: Desktop with ARM64 support
• .NET Version: 9.0.8 (built from source)
• Environment Mode: Development (also fails in Production)

Error Details

System.InvalidOperationException: Error while validating the service descriptor 'ServiceType: AspNetCore.Authentication.Basic.IBasicUserValidationService Lifetime: Transient ImplementationType: AiCoreApi.Authorization.BasicUserValidationService': Cannot consume scoped service 'AiCoreApi.Data.Processors.ISettingsProcessor' from singleton 'AiCoreApi.Common.ExtendedConfig'.

Root Cause Analysis

The issue stems from incompatible service lifetimes in Startup.cs:

1. Line 53-55: All interfaces matching ^I.*Processor$ are registered as Scoped

   services.ForInterfacesMatching("^I.*Processor$")
       .OfAssemblies(Assembly.GetExecutingAssembly())
       .AddScoped();

2. Line 77: ExtendedConfig is registered as Singleton

   services.AddSingleton<ExtendedConfig>();

3. ExtendedConfig.cs:22: The constructor depends on ISettingsProcessor

   public ExtendedConfig(ISettingsProcessor settingsProcessor)
   {
       _settingsProcessor = settingsProcessor;
   }

This violates ASP.NET Core's rule that singleton services cannot depend on scoped services.

Why This Works on Windows but Not macOS/Linux

The issue likely goes unnoticed on Windows because:

• Development environments on Windows might default to Production mode where validation is less strict
• The early call to services.BuildServiceProvider() on line 80 triggers validation before environment settings take effect
• Windows deployments might have different configuration or modified code

Steps to Reproduce

1. Clone the repository on macOS or Linux
2. Build Docker images from source:

   docker build -f AiCoreApi/Dockerfile -t aicore-api:latest . --platform linux/arm64

3. Run the container
4. Observe the DI validation error preventing startup

[justinmiller62]

Fix for Dependency Injection Issue - Successfully Tested on macOS ARM64

Problem Confirmed

I can confirm this issue on macOS (Darwin 24.4.0) with ARM64 architecture. The application fails to start due to the singleton ExtendedConfig attempting to consume the scoped ISettingsProcessor service.

Solution Implemented: Service Locator Pattern

After analyzing several options, I successfully fixed the issue using the Service Locator pattern. This approach maintains ExtendedConfig as a singleton while properly handling the scoped dependency.

Changes Made to AiCoreApi/Common/ExtendedConfig.cs:

1. Added using statement:

using Microsoft.Extensions.DependencyInjection;

2. Changed the dependency from ISettingsProcessor to IServiceProvider:

// Before:
private readonly ISettingsProcessor _settingsProcessor;

public ExtendedConfig(ISettingsProcessor settingsProcessor)
{
    _settingsProcessor = settingsProcessor;
}

// After:
private readonly IServiceProvider _serviceProvider;

public ExtendedConfig(IServiceProvider serviceProvider)
{
    _serviceProvider = serviceProvider;
}

3. Modified the Reset() method to create a scope:

// Before:
public void Reset()
{
    lock (_lock)
    {
        if (DateTime.Now > _nextRefresh)
        {
            _configValues = new ConcurrentDictionary<string, string>(_settingsProcessor.Get(SettingType.Common));
            _nextRefresh = DateTime.Now.AddSeconds(RefreshTimeSec);
        }
    }
}

// After:
public void Reset()
{
    lock (_lock)
    {
        if (DateTime.Now > _nextRefresh)
        {
            using var scope = _serviceProvider.CreateScope();
            var settingsProcessor = scope.ServiceProvider.GetRequiredService<ISettingsProcessor>();
            _configValues = new ConcurrentDictionary<string, string>(settingsProcessor.Get(SettingType.Common));
            _nextRefresh = DateTime.Now.AddSeconds(RefreshTimeSec);
        }
    }
}

Testing Results

After applying this fix:

• ✅ Built Docker images successfully for ARM64 architecture
• ✅ Application starts without DI validation errors
• ✅ API is accessible and responding on port 8080
• ✅ All services (API, File Ingestion, PostgreSQL, Redis) running properly

Why This Solution Works

1. Maintains singleton performance: ExtendedConfig remains a singleton, preserving the 15-second cache refresh behavior
2. Proper scope management: Creates a new scope only when accessing the scoped ISettingsProcessor
3. No breaking changes: Doesn't affect other services that depend on ExtendedConfig
4. Clean disposal: The using statement ensures proper cleanup of the scope

Alternative Solutions Considered

1. Making ExtendedConfig scoped: Would impact performance due to per-request instantiation
2. Making ISettingsProcessor singleton: Risky due to Entity Framework DbContext dependencies
3. Removing early BuildServiceProvider call: Would require extensive Startup.cs refactoring

Environment Tested

• macOS Darwin 24.4.0 (ARM64/Apple Silicon)
• .NET 9.0.8
• Docker Desktop with ARM64 support
• Built from source using: docker build -f AiCoreApi/Dockerfile -t aicore-api:latest . --platform linux/arm64

Recommendation

This fix should be applied to enable cross-platform development support. The Service Locator pattern, while sometimes considered an anti-pattern, is the appropriate solution here for resolving service lifetime mismatches when a singleton needs to occasionally access scoped services.

The fix has been tested and is working successfully. Happy to provide a PR if this approach is acceptable to the maintainers.

[AKercha1]

Thanks @justinmiller62. This looks like a valid concern.

The root cause you described (singleton depending on scoped) is indeed a DI violation, and it makes sense that stricter validation on macOS/Linux is surfacing the issue.

The fix you proposed with IServiceProvider.CreateScope() is pragmatic: it keeps ExtendedConfig as a singleton, respects the scoped nature of ISettingsProcessor, and avoids large changes to Startup. While the Service Locator pattern is not ideal, in this context it is a reasonable compromise since ExtendedConfig only needs scoped access occasionally and isn’t part of the request pipeline itself.

We’ll review the PR if you submit it. Thanks for investigating and providing such a thorough write-up and verification across environments.