[Feature request]: Expose `EnableReloads` overload that accepts a custom `IOptionsMonitor<TOptions>` instance

[denisbredikhin]

Is your feature request related to a specific problem? Or an existing feature?

Currently, AddResiliencePipelineContext.EnableReloads<TOptions>() only supports enabling reloads via an IOptionsMonitor<TOptions> that is resolved from DI:

RegistryContext.EnableReloads(
    ServiceProvider.GetRequiredService<IOptionsMonitor<TOptions>>(),
    name);

This makes it impossible to enable reloads for custom or external IOptionsMonitor<TOptions> implementations that are not registered in DI as IOptionsMonitor<TOptions>.

This limitation prevents several legitimate and advanced scenarios, such as:

• Using a custom options system not based on Microsoft.Extensions.Options
• Wrapping another configuration source (feature flags, remote config, tenant-specific config, etc.)
• Sharing a single monitor instance across multiple pipelines without DI registration
• Avoiding DI pollution when the monitor is internal or pipeline-specific

Describe the solution you'd like

Expose an additional public overload that allows explicitly supplying an IOptionsMonitor<TOptions> instance:

public void EnableReloads<TOptions>(
    IOptionsMonitor<TOptions> monitor,
    string? name = null)
    where TOptions : class;

This would internally forward to the existing infrastructure currently wired via RegistryContext.EnableReloads(...).

Expected behavior:

• The pipeline is rebuilt when monitor.OnChange fires
• name continues to behave the same way as in the existing overload
• No change in behavior for existing users

This overload would be purely additive and backward-compatible.

Additional context

No response

[martincostello]

Sorry, I don't quite follow the chain-of-thought here.

The methods accept an IOptionsMonitor<TOptions> - there's no requirement to use IServiceProvider to resolve that.

There's a test here that does exactly that:

Polly/test/Polly.Extensions.Tests/Registry/ConfigureBuilderContextExtensionsTests.cs

Lines 10 to 24 in c1ee1e5

	[Fact]
	public async Task ConfigureReloads_NullArguments_Throws()
	{
	await using var registry = new ResiliencePipelineRegistry<string>();
	registry.GetOrAddPipeline("pipeline", (_, builderContext) =>
	{
	ConfigureBuilderContext<string> nullContext = null!;
	IOptionsMonitor<Options> nullMonitor = null!;
	var monitor = Substitute.For<IOptionsMonitor<Options>>();
	Assert.Throws<ArgumentNullException>("context", () => nullContext.EnableReloads(monitor));
	Assert.Throws<ArgumentNullException>("optionsMonitor", () => builderContext.EnableReloads(nullMonitor));
	});
	}

[denisbredikhin]

@martincostello thanks for quick response.
Overload that accept IOptionsMonitor<TOptions> exist for ConfigureBuilderContext but not for AddResiliencePipelineContext so I can't use it from AddResiliencePipeline or AddResilienceHandler method.

[martincostello]

I'm not sure where we'd put any new API, as these methods are currently in the DependencyInjection namespace and/or are extensions of IServiceCollection.

The AddResiliencePipelineContext class is already specifically tightly-coupled to IServiceProvider.

It's less "add a new method" as "implement a whole new alternative way to do reloads".

[denisbredikhin]

Alternative solution for me can be making RegistryContext public. Then I could just call EnableReloads extension of it.

[martincostello]

Either way, this needs some deliberate design work to ensure we add the right things to the public API surface in a sustainable way.

[denisbredikhin]

Ok, will you consider adding this feature? Or do you need some more information or help from my side?

[martincostello]

It sounds reasonable as an idea, but I'm just clarifying that it's not "just" adding an overload.