You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
refactor: Make composite FlowKey the canonical ID (#1340)
This commit establishes the composite `types.FlowKey` (ID + Priority) as
the canonical identifier for a flow instance throughout the entire flow
control system. This architectural shift aligns the implementation with
the clarified domain model where a flow's priority is immutable.
This change is the result of a key architectural decision to simplify
the system's state management. The previous model, which treated
priority as a mutable attribute, required a complex state machine to
handle graceful updates. By making the `FlowKey` immutable, that
complexity is no longer necessary.
The key benefits of this new model are:
1. **Radical State Simplification:** The entire state machine for
handling priority updates has been removed. The concepts of "active"
vs. "draining" queues, generation counters, and queue reactivation
logic are now obsolete. This makes the `FlowRegistry` and
`ManagedQueue` implementations significantly simpler and more
robust.
2. **Unambiguous API Contracts:** Interfaces are now clearer. Methods
like `ManagedQueue(key types.FlowKey)` receive a single,
self-contained identifier, eliminating the need to pass `flowID` and
`priority` as separate parameters and removing any ambiguity about a
flow's identity.
3. **Architectural Alignment:** The implementation now correctly and
directly reflects the API's expectation that a flow instance is
uniquely defined by its ID *and* its priority.
**Architectural Consequence & Accepted Trade-off:**
This commit knowingly accepts a significant trade-off: inter-flow
fairness is now strictly siloed within each priority band.
Under this model, the system will never be able to reason about holistic
fairness for a single tenant across multiple priority levels (e.g.,
balancing `TenantA-High` against `TenantA-Medium`). Fairness policies
now operate on `(flowID, priority)` pairs as distinct, unrelated
entities.
This trade-off is considered acceptable because the requirement for
holistic, cross-priority fairness is currently undefined and out of
scope for the system's immediate goals.
0 commit comments