AddNavigationProvider<T>() registers a Scoped provider consumed by a Transient/Singleton IUndoRedoService, so DI scope validation throws for both documented setups

[matt-edmondson]

What's wrong

AddNavigationProvider<TNavigationProvider>() (UndoRedo/ServiceCollectionExtensions.cs ~L83-89) uses TryAddScoped<INavigationProvider, TNavigationProvider>(). But UndoRedoService, which takes INavigationProvider? in its constructor, is registered Transient by AddUndoRedo() (~L34) and Singleton by AddSingletonUndoRedo() (~L76). A scoped dependency of a singleton (or of a transient resolved from the root) is a captive dependency, which Microsoft.Extensions.DependencyInjection rejects under ValidateScopes/ValidateOnBuild — both on by default in the generic host's Development environment.

Failure scenarios (reproduced with temporary MSTest tests)

• AddSingletonUndoRedo() + AddNavigationProvider<Nav>() (the natural desktop-app setup):
  BuildServiceProvider(new ServiceProviderOptions { ValidateOnBuild = true, ValidateScopes = true }) throws
  AggregateException ... Cannot consume scoped service 'ktsu.UndoRedo.INavigationProvider' from singleton 'ktsu.UndoRedo.Contracts.IUndoRedoService'.
  Without validation, the singleton silently captures a provider resolved from the root scope, so "scoped" never actually applies.
• AddUndoRedo() + AddNavigationProvider<Nav>() (what docs/dependency-injection.md ~L123-126 recommends "for most applications"):
  resolving IUndoRedoService from the root provider with ValidateScopes = true throws
  InvalidOperationException: Cannot resolve 'ktsu.UndoRedo.Contracts.IUndoRedoService' from root provider because it requires scoped service 'ktsu.UndoRedo.INavigationProvider'.

So a consumer following the docs gets a startup crash under Host.CreateDefaultBuilder in Development.

Suggested fix

Make the navigation provider's lifetime compatible with the undo/redo registration — e.g. change AddNavigationProvider<T> to TryAddTransient, or deprecate the scoped variant and direct users to AddSingletonNavigationProvider alongside AddSingletonUndoRedo. Update the lifetime table / "Scoped Navigation Provider" section in docs/dependency-injection.md to match.

Acceptance criteria

• Tests build a provider with ValidateOnBuild = true, ValidateScopes = true for each supported pairing (AddUndoRedo/AddSingletonUndoRedo × each Add*NavigationProvider) and resolve IUndoRedoService from the root without exceptions — or unsupported pairings are removed/documented.

[matt-edmondson]

Triage

• Category: Bug
• Priority: High. Both documented DI setups crash at startup under Host.CreateDefaultBuilder in Development, because ValidateScopes and ValidateOnBuild are on by default there. When validation is off, the singleton silently captures a provider from the root scope. Following docs/dependency-injection.md is enough to hit it.
• Area / suggested assignee: ServiceCollectionExtensions.AddNavigationProvider<T>, AddUndoRedo and AddSingletonUndoRedo, plus the lifetime table in docs/dependency-injection.md. Owner: @matt-edmondson
• Duplicates / in progress: not a duplicate. None of the open PRs in this repo touch DI registration: Resolve a held save boundary to its live position before undoing to it #101 covers save boundaries, Clamp GetCommandsInRange against the remaining commands so a large count cannot overflow [patch] #106 covers range clamping and Treat an out-of-range navigation timeout as no timeout instead of throwing after undo/redo [patch] #107 covers the navigation timeout.
• Next step: choose between switching AddNavigationProvider<T> to TryAddTransient and deprecating the scoped variant in favour of AddSingletonNavigationProvider. Changing a registered lifetime is observable to consumers, so it may need a [minor] bump. Then add validation-on tests for every pairing of undo/redo registration and navigation-provider registration.

---

Generated by Claude Code

[matt-edmondson]

Decision (maintainer, 2026-09-28)

• Keep the navigation provider and fix its lifetime: change AddNavigationProvider<T> to TryAddTransient. Do not deprecate the scoped variant in favour of AddSingletonNavigationProvider.
• The maintainer wants UndoRedo to support ktsu.Navigation ("I want UndoRedo to support ktsu.Navigation"), so the navigation integration should target ktsu.Navigation.
• Circular dependency warning: Delegate undo/redo to ktsu.UndoRedo Navigation#46 was decided the same day. Navigation will adopt ktsu.UndoRedo behind an adapter, which creates a Navigation → UndoRedo dependency. The Navigation integration therefore must not be a package reference from UndoRedo.Core to ktsu.Navigation. Two ways to avoid that:
  • a separate integration package, for example ktsu.UndoRedo.Navigation
  • Navigation implementing UndoRedo's INavigationProvider

Next reader: switch to TryAddTransient and update the lifetime table in docs/dependency-injection.md. Add validation-on tests (ValidateOnBuild/ValidateScopes) for every pairing of undo/redo registration and navigation-provider registration. Design the Navigation integration together with Navigation#46 so that no cycle exists.

---

Generated by Claude Code