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
{{ message }}
Repository navigation
Orchestrator: shift windows break VROOM runs, plus time window, capacity and greedy engine gaps #365
Running the orchestrator on v0.7.68 (fleetops 0.6.71) with VROOM 1.15, we hit these problems in OrchestrationPayloadBuilder and the greedy engine, most important first:
Vehicle and driver shifts make every VROOM run fail with Invalid time-window. time_window_start/end are TIME columns with no cast, and the builder reads ->timestamp on the strings, so VROOM gets [null, null].
The order's time window goes on the delivery step only, so for pickup orders it lands on the depot drop. Waypoint time_window_* are never read, and driver schedules use activeShiftFor(now()), so a plan for tomorrow uses today's shifts.
A vehicle without payload_capacity_volume gets volume capacity 0, so orders whose entities have dimensions can never be assigned to it. payload_capacity_unit is never read (always kg), and driver max_distance is never sent to VROOM.
The greedy engine reads $order->payload?->pickup?->lat, which Place doesn't have, so every distance is 0. With allow_multi_order it put all 150 of our test orders (17,360 lb) on the first van (2,000 lb capacity).
The v1 Order resource doesn't return time_window_start/end, required_skills or orchestrator_priority, so clients can set them but not read them back.
Proposed fixes
Parse HH:MM[:SS] onto the plan date (the run's scheduled_date, or today), and leave the window out when a bound is missing.
Put each window on the step it belongs to, read waypoint windows, and use activeShiftFor($scheduledDate).
Leave out a capacity dimension that no vehicle in the run defines, convert payload_capacity by its unit, and send max_distance next to max_travel_time.
Use $pickup->location->getLat() / getLng() and the capacity and skills helpers the VROOM path already has.
Shifts can't be used with VROOM at all, and the other gaps produce plans that look valid but ignore the constraints.
Why
Most of these are small, local fixes, and together they make the orchestrator usable for shift-based dispatch. We're happy to send PRs; let us know if you'd like one PR or several.
Describe the bug
Running the orchestrator on v0.7.68 (fleetops 0.6.71) with VROOM 1.15, we hit these problems in
OrchestrationPayloadBuilderand the greedy engine, most important first:Invalid time-window.time_window_start/endareTIMEcolumns with no cast, and the builder reads->timestampon the strings, so VROOM gets[null, null].time_window_*are never read, and driver schedules useactiveShiftFor(now()), so a plan for tomorrow uses today's shifts.payload_capacity_volumegets volume capacity 0, so orders whose entities have dimensions can never be assigned to it.payload_capacity_unitis never read (always kg), and drivermax_distanceis never sent to VROOM.$order->payload?->pickup?->lat, whichPlacedoesn't have, so every distance is 0. Withallow_multi_orderit put all 150 of our test orders (17,360 lb) on the first van (2,000 lb capacity).time_window_start/end,required_skillsororchestrator_priority, so clients can set them but not read them back.Proposed fixes
HH:MM[:SS]onto the plan date (the run'sscheduled_date, or today), and leave the window out when a bound is missing.activeShiftFor($scheduledDate).payload_capacityby its unit, and sendmax_distancenext tomax_travel_time.$pickup->location->getLat()/getLng()and the capacity and skills helpers the VROOM path already has.Http/Resources/v1/Order.php, as Expand public Fleet, Vehicle, and Driver API contracts #311 did for vehicles and drivers.Impact
Shifts can't be used with VROOM at all, and the other gaps produce plans that look valid but ignore the constraints.
Why
Most of these are small, local fixes, and together they make the orchestrator usable for shift-based dispatch. We're happy to send PRs; let us know if you'd like one PR or several.