Drop WorkflowId.namespace, introduce WorkflowGroup#901
Merged
Conversation
WorkflowFactory tracks the backend service name for each registered spec, defaulting to the spec's namespace. JobFactory consults this tag via get_service() instead of comparing workflow_id.namespace against Instrument.active_namespace. service_name is threaded from DataServiceBuilder through OrchestratingProcessor into JobFactory, and is also the single source for the service heartbeat's namespace field (wire format unchanged here; renamed in 0b). The dead Instrument.active_namespace write in DataServiceBuilder is removed. The field itself stays on Instrument until 0e so tests referencing it remain valid. Stage 0a of docs/developer/plans/ess-livedata-schemas-stage0.md.
The field was overloaded: identity-for-worker-routing in the dashboard plus display label in the backend status widget. Both uses describe the backend service, not a namespace. Renaming across ServiceStatus (domain type), ServiceStatusPayload (wire payload), and ServiceServiceId (the `:`-separated service_id) makes the semantics explicit. The service_id wire string format (`instrument:<middle>:worker_id`) is unchanged — the middle segment still carries the service name, just sourced from .service_name now. BackendStatusWidget's "Namespace" column becomes "Service"; internal pane + width constants renamed to match. Stage 0b of docs/developer/plans/ess-livedata-schemas-stage0.md.
Stage 0d of ess-livedata-schemas: introduces a `WorkflowGroup` pydantic model (frozen, `Literal`-constrained name) with canonical module-level constants `REDUCTION`, `MONITORS`, `DETECTORS`, `TIMESERIES`. Adds a required `group: WorkflowGroup` field to `WorkflowSpec` so display metadata travels alongside the spec. `Instrument.register_spec` and `Instrument.add_logical_view` now take a `group=` argument in place of `namespace=`, deriving the legacy `WorkflowSpec.namespace` value from `group.name` until 0e drops it. Omits the `params`→`inputs` rename from the plan; not strictly necessary at this point.
Stage 0e of ess-livedata-schemas. `WorkflowId` identity becomes `(instrument, name, version)` and `WorkflowSpec.namespace` is removed; `group` (added in 0d) now carries the display category and, by default, the service tag. `WorkflowId.__str__`/`from_string` use the 3-part `instrument/name/version` form. `Instrument.active_namespace` (unused since 0a) is removed. The dashboard plot-config modal switches its workflow grouping from `workflow_id.namespace` to `spec.group.name`/`spec.group.title`, with the synthetic static-overlay sentinel renamed accordingly. No wire-format compatibility — JobStatusPayload workflow_id strings, ResultKey JSON, and persisted configs all pick up the 3-part form.
SimonHeybrock
changed the title
WorkflowId.namespace, introduce WorkflowGroupWorkflowId.namespace, introduce WorkflowGroup
jl-wynen
reviewed
Apr 29, 2026
Member
jl-wynen
left a comment
jl-wynen
left a comment
There was a problem hiding this comment.
I think it makes sense to split display grouping and job assignment.
Can you remind me what a 'service' is exactly?
Is it safe to drop the 'namespace' / 'service' from WorkflowId? Or can there be clashes now?
| group: | ||
| Display-oriented :class:`WorkflowGroup` this view belongs to. | ||
| The group's ``name`` (e.g. ``'detector_data'`` or ``'monitor_data'``) | ||
| also determines which service runs the workflow today. |
| service: | ||
| Name of the backend service responsible for running this workflow. | ||
| Defaults to ``group.name`` (service and group identifier match | ||
| today; the coupling is removed in a later stage). |
Member
There was a problem hiding this comment.
(service and group identifier match today; the coupling is removed in a later stage)
This doesn't sound like an explanation for a user but a commit/PR comment.
Is it correct that currently service == group.name everywhere?
Member
Author
Backend is split into shards ("services"), handling different subsets of workflows.
Did check for clashing during this work and found none. Option for clashes existed even before, now we simply have a larger set of workflows that need unique names. |
- Add missing `service` parameter doc to `add_logical_view` - Remove temporal "today; the coupling is removed in a later stage" language from `service` param docs in both `instrument.py` and `workflow_factory.py`
jl-wynen
approved these changes
Apr 30, 2026
Member
jl-wynen
left a comment
jl-wynen
left a comment
There was a problem hiding this comment.
I think it makes sense to split display grouping and job assignment.
Can you remind me what a 'service' is exactly?
Is it safe to drop the 'namespace' / 'service' from WorkflowId? Or can there be clashes now?
MridulS
pushed a commit
that referenced
this pull request
May 11, 2026
PR #901 dropped the namespace segment from WorkflowId. Existing dashboard config YAMLs still hold 4-part IDs; this script rewrites them to the new 3-part form, with .bak backups and atomic writes. Idempotent.
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
2 participants
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
Reduces
WorkflowIdidentity from(instrument, namespace, name, version)to(instrument, name, version)and replaces thenamespacefield with a display-orientedWorkflowGroup.Why
WorkflowSpec.namespacewas carrying three unrelated responsibilities: workflow identity, the routing keyJobFactoryused to accept/reject jobs, and the dashboard's display category. Splitting them:servicetag tracked byWorkflowFactory, consulted viaget_service(workflow_id). The service's own name is the comparison key, no longer read fromWorkflowId.WorkflowGroupwith canonicalREDUCTION/MONITORS/DETECTORS/TIMESERIESconstants and aLiteral-lockednameto keep ad-hoc categories from sneaking in.WorkflowIdstrings are now 3-part (instrument/name/version).With the awkward semantics gone, the upcoming move into
ess.livedata.schemasbecomes mechanical.Note
JobStatusPayloadworkflow-id strings,ResultKeyJSON, and persisted configs all pick up the 3-part form.