|
| 1 | +# Flow Controller Intra-Flow Dispatch Policy Plugins |
| 2 | + |
| 3 | +This directory contains concrete implementations of the [`framework.IntraFlowDispatchPolicy`](../../../policies.go) |
| 4 | +interface. These policies are responsible for **temporal scheduling**: determining the order in which requests are |
| 5 | +selected for dispatch *from within a single flow's queue*. |
| 6 | + |
| 7 | +## Overview |
| 8 | + |
| 9 | +The `controller.FlowController` uses a two-tier policy system to manage requests. `framework.IntraFlowDispatchPolicy` |
| 10 | +plugins represent the first tier, making tactical decisions about the ordering of requests *within* a single logical |
| 11 | +flow (e.g., for a specific model or tenant). |
| 12 | + |
| 13 | +This contrasts with the `framework.InterFlowDispatchPolicy` (not yet implemented), which is responsible for |
| 14 | +**spatial fairness**: deciding *which flow's queue* gets the next opportunity to dispatch a request. The |
| 15 | +`framework.IntraFlowDispatchPolicy` only operates *after* the inter-flow policy has selected a specific queue. |
| 16 | + |
| 17 | +Key responsibilities and characteristics of a `framework.IntraFlowDispatchPolicy`: |
| 18 | + |
| 19 | +1. **Request Selection (`SelectItem`)**: The primary method, `SelectItem(queue framework.FlowQueueAccessor)`, inspects |
| 20 | + the given flow's queue (via a read-only accessor) and decides which item, if any, should be dispatched next from |
| 21 | + *that specific queue*. |
| 22 | + |
| 23 | +2. **Priority Definition (`ItemComparator`)**: |
| 24 | + - This policy type is unique because it defines the nature of priority for items *within its specific managed |
| 25 | + queue*. It makes this logic explicit by vending a [`framework.ItemComparator`](../../../policies.go). |
| 26 | + - The vended comparator defines the "less than" relationship between two items and exposes a `ScoreType()` string |
| 27 | + (e.g., `"enqueue_time_ns_asc"`, `"slo_deadline_urgency"`) that gives a semantic meaning to the comparison. |
| 28 | + |
| 29 | +3. **Queue Compatibility (`RequiredQueueCapabilities`)**: The policy specifies the capabilities its associated |
| 30 | + [`framework.SafeQueue`](../../../queue.go) must support for it to function correctly. For example, a simple FCFS |
| 31 | + policy would require `framework.CapabilityFIFO`, while a more complex, priority-based policy would require |
| 32 | + `framework.CapabilityPriorityConfigurable`. The `ports.FlowRegistry` uses this information to pair policies with |
| 33 | + compatible queues. |
| 34 | + |
| 35 | +The `framework.IntraFlowDispatchPolicy` allows for fine-grained control over how individual requests within a single flow are |
| 36 | +serviced, enabling strategies like basic FCFS or more advanced schemes based on SLOs or deadlines. |
| 37 | + |
| 38 | +## Contributing a New `framework.IntraFlowDispatchPolicy` Implementation |
| 39 | + |
| 40 | +To contribute a new dispatch policy implementation, follow these steps: |
| 41 | + |
| 42 | +1. **Define Your Implementation** |
| 43 | + - Create a new Go package in a subdirectory (e.g., `mycustompolicy/`). |
| 44 | + - Implement the `framework.IntraFlowDispatchPolicy` interface. |
| 45 | + - Ensure all methods are goroutine-safe if your policy maintains any internal state. |
| 46 | + |
| 47 | +2. **Register Your Policy** |
| 48 | + - In an `init()` function within your policy's Go file, call [`MustRegisterPolicy()`](./factory.go) with a |
| 49 | + unique name and a constructor function that matches the `PolicyConstructor` signature. |
| 50 | + |
| 51 | +3. **Add to the Functional Test** |
| 52 | + - Add a blank import for your new package to [`functional_test.go`](./functional_test.go). Your policy will then |
| 53 | + be automatically included in the functional test suite, which validates the basic |
| 54 | + `framework.IntraFlowDispatchPolicy` contract (e.g., correct initialization, handling of nil/empty queues). |
| 55 | + |
| 56 | +4. **Add Policy-Specific Tests** |
| 57 | + - The functional test suite only validates the universal contract. You MUST add a separate `_test.go` file within |
| 58 | + your package to test the specific logic of your policy. |
| 59 | + - For example, your tests should validate that your `Comparator()` works as expected and that `SelectItem()` |
| 60 | + correctly implements your desired selection logic for a non-empty queue. |
| 61 | + |
| 62 | +5. **Documentation** |
| 63 | + - Add a package-level GoDoc comment to your new policy's Go file, explaining its behavior and any trade-offs. |
0 commit comments