git.stella-ops.org/docs/dev/authority-plugin-di-coordination.md

Authority Plug-in Scoped Service Coordination

Created: 2025-10-19 — Plugin Platform Guild & Authority Core
Status: Completed (workshop held 2025-10-20 15:00–16:05 UTC)

This document tracks preparation, agenda, and outcomes for the scoped-service workshop required before implementing PLUGIN-DI-08-002.

Objectives

• Inventory Authority plug-in surfaces that need scoped service lifetimes.
• Confirm session/scope handling for identity-provider registrars and background jobs.
• Assign follow-up tasks/actions with owners and due dates.

Scheduling Snapshot

• Meeting time: 2025-10-20 15:00–16:00 UTC (10:00–11:00 CDT / 08:00–09:00 PDT).
• Facilitator: Plugin Platform Guild — Alicia Rivera.
• Attendees (confirmed): Authority Core — Jasmin Patel; Authority Security Guild — Mohan Singh; Plugin Platform — Alicia Rivera, Leah Chen.
• Optional invitees: DevOps liaison — Sofia Ortega (accepted).
• Logistics: Invites sent via shared calendar on 2025-10-19 15:30 UTC with Teams bridge + offline dial-in. Meeting notes will be captured here.
• Preparation deadline: 2025-10-20 12:00 UTC — complete checklist below.

Pre-work Checklist

• Review ServiceBindingAttribute contract introduced by PLUGIN-DI-08-001.
• Collect existing Authority plug-in registration code paths to evaluate.
• Audit background jobs that assume singleton lifetimes.
• Identify plug-in health checks/telemetry surfaces impacted by scoped lifetimes.

Pre-work References

Focus	Path	Notes
Host DI wiring	src/Authority/StellaOps.Authority/StellaOps.Authority/Program.cs:159	Startup registers IAuthorityIdentityProviderRegistry as a singleton and invokes AuthorityPluginLoader.RegisterPlugins(...) before the container is built. Any scoped plugin services will currently be captured in the singleton registry context.
Registrar discovery	src/Authority/StellaOps.Authority/StellaOps.Authority/Plugins/AuthorityPluginLoader.cs:46	Loader instantiates IAuthorityPluginRegistrar implementations via Activator.CreateInstance, so registrars cannot depend on host services yet. Need agreement on whether to move discovery post-build or introduce ActivatorUtilities.
Registry aggregation	src/Authority/StellaOps.Authority/StellaOps.Authority/AuthorityIdentityProviderRegistry.cs:16	Registry caches IIdentityProviderPlugin instances at construction time. With scoped lifetimes we must revisit how providers are resolved (factory vs accessor).
Standard registrar services	src/Authority/StellaOps.Authority/StellaOps.Authority.Plugin.Standard/StandardPluginRegistrar.cs:21	All plugin services are registered as singletons today (StandardUserCredentialStore, StandardClientProvisioningStore, hosted bootstrapper). This registrar is our baseline for migrating to scoped bindings.
Hosted bootstrapper	src/Authority/StellaOps.Authority/StellaOps.Authority.Plugin.Standard/Bootstrap/StandardPluginBootstrapper.cs:17	Background job directly consumes StandardUserCredentialStore. If the store becomes scoped we will need an IServiceScopeFactory bridge.
Password grant handler	src/Authority/StellaOps.Authority/StellaOps.Authority/OpenIddict/Handlers/PasswordGrantHandlers.cs:26	Password flow resolves IIdentityProviderPlugin during scoped requests. Scope semantics must ensure credential stores stay cancellation-aware.
Client credential handler	src/Authority/StellaOps.Authority/StellaOps.Authority/OpenIddict/Handlers/ClientCredentialsHandlers.cs:21	Handler fetches provider + ClientProvisioning store; confirms need for consistent scoping in both user and client flows.

Preliminary Findings — 2025-10-20

• IAuthorityIdentityProviderRegistry must stop materialising provider singletons when scoped lifetimes land. Options to evaluate: make the registry itself scoped, convert it to a factory over IServiceProvider, or cache lightweight descriptors and resolve implementations on-demand.
• AuthorityPluginLoader instantiates registrars without DI support. To let registrars request scoped helpers (e.g. IServiceScopeFactory) we may need a two-phase registration: discover types at build time, defer execution until the container is available.
• Hosted bootstrap tasks (e.g. StandardPluginBootstrapper) will break if their dependencies become scoped. Workshop should align on using scoped pipelines inside StartAsync or shifting bootstrap work to queued jobs.
• Standard plugin stores assume singleton access to Mongo collections and password hashing utilities. If we embrace scoped stores, document thread-safety expectations and reuse of Mongo clients across scopes.
• OpenIddict handlers already run as scoped services; once providers move to scoped lifetimes we must ensure the new resolution path stays cancellation-aware and avoids redundant service resolution per request.
• 2025-10-20 (PLUGIN-DI-08-003): Registry implementation updated to expose metadata + scoped handles; OpenIddict flows, bootstrap endpoints, and /health now resolve providers via scoped leases with accompanying test coverage.
• 2025-10-20 (PLUGIN-DI-08-004): Authority plugin loader now instantiates registrars via scoped DI activations and honours [ServiceBinding] metadata in plugin assemblies.
• 2025-10-20 (PLUGIN-DI-08-005): StandardPluginBootstrapper shifted to scope-per-run execution using IServiceScopeFactory, enabling future scoped stores without singleton leaks.

Draft Agenda

1. Context recap (5 min) — why scoped DI is needed; summary of PLUGIN-DI-08-001 changes.
2. Authority plug-in surfaces (15 min) — registrars, background services, telemetry.
3. Session handling strategy (10 min) — scope creation semantics, cancellation propagation.
4. Action items & owners (10 min) — capture code/docs/test tasks with due dates.
5. Risks & follow-ups (5 min) — dependencies, rollout sequencing.

Notes

• Session opened with recap of scoped-service goals and PLUGIN-DI-08-001 changes, confirming Authority readiness to adopt [ServiceBinding] metadata.
• Agreed to treat IAuthorityIdentityProviderRegistry as a scoped-factory facade rather than a singleton cache; registry will track descriptors and resolve implementations on-demand per request/worker scope.
• Standard plug-in bootstrap will create scopes via IServiceScopeFactory and pass cancellation tokens through to avoid lingering singleton references.
• Authority Plugin Loader will enumerate plug-in assemblies at startup but defer registrar activation until a scoped service provider is available, aligning with PLUGIN-DI-08-004 implementation.
• Follow-up engineering tasks assigned to land PLUGIN-DI-08-002 code path adjustments and Authority host updates before 2025-10-24.

Action Item Log

Item	Owner	Due	Status	Notes
Confirm meeting time	Alicia Rivera	2025-10-19 15:30 UTC	DONE	Calendar invite sent; all required attendees accepted
Compile Authority plug-in DI entry points	Jasmin Patel	2025-10-20	DONE (2025-10-20)	Scoped-service touchpoints summarised in Pre-work References and Preliminary Findings ahead of the workshop.
Outline scoped-session pattern for background jobs	Leah Chen	2025-10-21	DONE (2025-10-20)	Pattern agreed: bootstrap services must open transient scopes per execution via IServiceScopeFactory; document update to follow in PLUGIN-DI-08-002 patch.
Update PLUGIN-DI-08-002 implementation plan	Alicia Rivera	2025-10-21	DONE (2025-10-20)	Task board + SPRINTS updated with scoped-integration delivery notes and test references.
Sync Authority host backlog	Mohan Singh	2025-10-21	DONE (2025-10-20)	Authority/Plugin TASKS.md and SPRINTS entries reflect scoped-service completion.