deepdrft/product-notes/blazorblocks-modelview-di-registration-brief.md

Index — EditModalSaveContextHolder Missing DI Registration (BlazorBlocks / AuthBlocks)

Status: ✅ RESOLVED — shipped in Cerebellum.BlazorBlocks.Web 10.3.33 + Cerebellum.AuthBlocks.Web 10.3.36 (2026-06-20). scoped, not yet started. Confirmed against Cerebellum.BlazorBlocks.Web 10.3.32 / Cerebellum.AuthBlocks.Web 10.3.33. Author: product-designer. Date: 2026-06-19.

Resolution (2026-06-20): AddBlazorBlocksWeb() landed in Cerebellum.BlazorBlocks.Web 10.3.33 and ConfigureAuthServices calls it in Cerebellum.AuthBlocks.Web 10.3.36; DeepDrftManager picked up 10.3.36 and removed its local EditModalSaveContextHolder stopgap. This brief is retained as historical record — no further action required.

The defect

BlazorBlocks' ModelView / EditModelModal components have a required [Inject] dependency on Web.Maintenance.Entities.EditModalSaveContextHolder (a per-circuit save bridge), but the BlazorBlocks Web package ships no registration extension for it and AuthBlocks' ConfigureAuthServices never registers it either. Any consumer of a ModelView-based page (e.g. AuthBlocks' Users.razor / Registrations.razor) crashes the Blazor circuit on navigation with an unregistered-service InvalidOperationException. Two independent downstream products have each hand-registered the internal service as a stopgap — the tell that this is a leaked library registration.

The two-team layered fix (ordered — do not reorder)

1. BlazorBlocks ships first. Add a Web-side AddBlazorBlocksWeb() extension that registers the holder via TryAddScoped (scoped is required). Bump Cerebellum.BlazorBlocks.Web from 10.3.32; report the new version.
2. AuthBlocks ships second. Bump its Cerebellum.BlazorBlocks.Web reference to that new version, call AddBlazorBlocksWeb() from ConfigureAuthServices, bump Cerebellum.AuthBlocks.Web from 10.3.33.

AuthBlocks is blocked until BlazorBlocks' new version is published. Registration lives with its owner (BlazorBlocks); AuthBlocks stays self-contained by composing it. MudBlazor (AddMudServices) stays a caller-owned prerequisite throughout.

The detail lives in the two team briefs

Each is fully self-contained for an orchestrator working in only that one repo:

• BlazorBlocks team → team-brief-blazorblocks-modelview-di.md (root cause, [Inject] audit, lifetime rationale, the new extension, version bump, acceptance criteria).
• AuthBlocks team → team-brief-authblocks-modelview-di.md (the blocking BlazorBlocks prerequisite, the ConfigureAuthServices call, version bump, acceptance criteria).