14617e9c3b
- Added `SchedulerWorkerOptions` class to encapsulate configuration for the scheduler worker. - Introduced `PlannerBackgroundService` to manage the planner loop, fetching and processing planning runs. - Created `PlannerExecutionService` to handle the execution logic for planning runs, including impact targeting and run persistence. - Developed `PlannerExecutionResult` and `PlannerExecutionStatus` to standardize execution outcomes. - Implemented validation logic within `SchedulerWorkerOptions` to ensure proper configuration. - Added documentation for the planner loop and impact targeting features. - Established health check endpoints and authentication mechanisms for the Signals service. - Created unit tests for the Signals API to ensure proper functionality and response handling. - Configured options for authority integration and fallback authentication methods.
Scheduler Storage Mongo — Sprint 16 Handoff
This module now consumes the canonical DTOs defined in StellaOps.Scheduler.Models.
Samples covering REST shapes live under samples/api/scheduler/ and are referenced from docs/11_DATA_SCHEMAS.md#3.1.
Collections & DTO mapping
| Collection | DTO | Notes |
|---|---|---|
schedules |
Schedule |
Persist Schedule as-is. _id → Schedule.Id. Use compound indexes on {tenantId, enabled} and {whenCron} per doc. |
runs |
Run |
Store Run.Stats inside the document; omit deltas array when empty. |
impact_snapshots |
ImpactSet |
Normalise selector filter fields exactly as emitted by the canonical serializer. |
audit |
AuditRecord |
Lower-case metadata keys are already enforced by the model. |
All timestamps are persisted as UTC (+00:00). Empty selector filters remain empty arrays (see impact-set.json sample).
Implementation guidance
- Add a project reference to
StellaOps.Scheduler.Modelsand reuse the records directly; avoid duplicate BSON POCOs. - When serialising/deserialising to MongoDB, call
CanonicalJsonSerializerto keep ordering stable for diffable fixtures. - Integration tests should load the JSON samples and round-trip through the Mongo persistence layer to guarantee parity.
- Follow
docs/11_DATA_SCHEMAS.mdfor index requirements; update that doc if storage diverges. - Register
AddSchedulerMongoStoragein the host and callISchedulerMongoInitializer.EnsureMigrationsAsyncduring bootstrap so collections/indexes are created before workers/web APIs start.
With these artefacts in place the dependency on SCHED-MODELS-16-101/102 is cleared—storage work can move to DOING.
Repositories & Sessions (Sprint 16)
AddSchedulerMongoStoragenow registers the scheduler repositories:IScheduleRepository— CRUD helpers with tenant scoping and soft-delete markers (deletedAt,deletedBy).IRunRepository— create/update/list helpers sorted bycreatedAt, honouring the TTL index onfinishedAt.IImpactSnapshotRepository— stores canonicalImpactSetsnapshots with deterministic selector digests.IAuditRepository— append/list audit log entries with optional category/schedule/run filters.IRunSummaryRepository— persists therun_summariesmaterialised view keyed by tenant/schedule.IRunSummaryService— projects run updates into the materialised view (latest run + rolling counters for the last 20 updates).ISchedulerAuditService— convenience layer that stamps IDs/timestamps and writesAuditRecordinstances with consistent metadata.ISchedulerMongoSessionFactoryprovides causal-consistent Mongo sessions (defaultCausalConsistency = true) that repositories accept for read-after-write flows.- All repositories persist canonical JSON via
CanonicalJsonSerializer; helper mappers strip internal fields before materialising DTOs. - Soft-deleted schedules keep historical documents but are excluded from queries unless
ScheduleQueryOptions.IncludeDeletedis set; deletions also disable the schedule and bumpupdatedAt/updatedBy.