ConfigurePrimaryHttpMessageHandler configureHandler is never called

[Ghostbird]

When I call this in the ConfigureServices:

services
.AddHttpClient(clientName)
.ConfigurePrimaryHttpMessageHandler(configureHandler)

The configureHandler function is called and everything works properly.

However I must call:

services
.AddAuthentication()
.AddMyScheme();

/// Where AddMyScheme is defined as:
public static AuthenticationBuilder AddMyScheme(this AuthenticationBuilder builder, string authenticationScheme = "myScheem", string displayName = "MyScheme", Action<MyAuthOptions> configureOptions
=> builder.AddRemoteScheme(authenticationScheme, displayName, (MyAuthOptions options) => {
  {
    // Code to configure defaults snipped for brevity
    if (configureOptions is not null)
    {
      configureOptions(options);
    }
   builder.Services
    .AddHttpClient(options.HttpClientName)
    .ConfigurePrimaryHttpMessageHandler(configureHandler);
  }
);

In this case the configureHandler is never called for reasons obscured to me.

Note that this example is significantly simplified, and removes intricacies why the code must be called in this way, so I'll summarise:

I can only create the primary http message handler at that point, as that is the first point in time that the MyAuthOptions instance is available to my code. Because this instance of MyAuthOptions is the only way to communicate the HttpClientName to both the AddHttpClient and the underlying RemoteAuthenticationScheme.

The alternative to use services.AddHttpClient(clientName) at the ConfigureServices level, is extremely undesirable. The entire logic that requires a named HTTP client to be added with specific handler logic is entirely internal to my remote authentication scheme. All options are auto calculated based on the parameters to AddRemoteScheme.

To separate the two, would mean:

• Two separate actions must be undertaken by the caller before it works
• The arguments passed to the first of these actions, must be the predicted results of calculations that happen internally in the implementation details of the second action.

It's just not feasible.

Any idea how to solve this would be appreciated.