feat: shared IOperationsService for dashboard + GraphQL parity#60
Merged
feat: shared IOperationsService for dashboard + GraphQL parity#60
Conversation
Centralises the operations the dashboard UI performs (queue a train, cancel a queued entry, update a manifest group, build the cross-group dependency graph, compute dashboard metrics, read/update scheduler runtime config) into a single scoped service in Trax.Scheduler. Both the Blazor dashboard and the GraphQL operations.* namespace in Trax.Api now go through this service, so the two surfaces have identical validation, persistence, and result semantics by construction rather than by convention. Surfaced (and fixed) a bug in the dashboard where train-name lookup compared against the friendly ServiceTypeName instead of ServiceType.FullName. The scheduler-config side of the service writes through to the new trax.scheduler_config row in Trax.Effect and reads back from the in-memory singleton; SchedulerConfigBootstrapHostedService re-applies the persisted row on startup. 64 integration tests cover the four surfaces (work queue, manifest group, metrics, scheduler config) end-to-end against Postgres.
Codecov Report❌ Patch coverage is 📢 Thoughts on this report? Let us know! |
|
This PR is included in version 1.29.0 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Introduces `IOperationsService` in `Trax.Scheduler.Services.Operations` as the single source of truth for operations the dashboard UI performs. The Blazor dashboard and the upcoming React rebuild both call this service through the GraphQL `operations.*` namespace, so a queue/cancel/update/save from either surface produces the same DB write and the same in-memory mutation.
What it covers
Persistence
`UpdateSchedulerConfigAsync` writes to both the in-memory `SchedulerConfiguration` singleton (immediate effect) and the persisted `trax.scheduler_config` row (survives restart). `SchedulerConfigBootstrapHostedService` re-applies the persisted row to the singleton on app start.
Bug caught during extraction
The dashboard's `QueueTrainDialog` matched user-supplied train names against `TrainRegistration.ServiceTypeName` (a friendly name like `IServiceTrain<X, Y>`) rather than `ServiceType.FullName`. The shared service compares against FullName, per the Train Type Naming Rules in `CLAUDE.md`. Same fix automatically lands in the dashboard once `feat/dashboard-api-parity` (Trax.Dashboard) merges.
Coordinated changes
Depends on Trax.Effect `feat/scheduler-config-model` for the new model and DbSet. Consumed by Trax.Api `feat/operations-namespaces` and Trax.Dashboard `feat/operations-service-integration`.
Merge order: Trax.Effect → this PR → Trax.Api / Trax.Dashboard.
Test plan