Overview
When the VRP solver cannot assign certain jobs to any resource, it can now provide detailed reasons explaining why each job remains unassigned. This feature helps identify scheduling conflicts and constraints preventing job assignments.Enabling Unassigned Reasons
To receive unassigned reasons in your response, enable the explanation feature with theonlyUnassigned option:
Example Request
Here’s an example where jobs cannot be assigned due to time window conflicts:Example Response
The response includes anunservedReasons map that explains why each unassigned job could not be scheduled:
Common Unassigned Reasons
Use Cases
- Capacity Planning: Identify when you need more resources or extended shifts
- Schedule Optimization: Understand which constraints are most restrictive
- Customer Communication: Provide clear explanations for service limitations
- System Debugging: Quickly identify configuration issues preventing assignments
Incomplete Results
Reasons are derived from the alternative positions computed for each unassigned job, and that analysis is bounded (see Limiting the cost of alternatives). Every unserved job still gets an entry inunservedReasons, but a job that was not analysed gets an empty list - which
is indistinguishable from “no hard constraint blocked this job”. The solution carries an
explanationTruncation object whenever that can have happened:
explanationTruncation is absent.
Raise maxExplainedJobs and maxDurationMillis if you need the full picture on a large instance.
Performance Considerations
- Setting
onlyUnassigned: trueimproves performance by only analyzing unassigned jobs - For large problems, consider using this feature selectively during debugging
- The defaults (
maxDurationMillis: 30000,maxExplainedJobs: 500,maxAlternativesPerJob: 25) keep the analysis bounded; without them a heavily unassigned instance can produce gigabytes of alternatives - The explanation process runs after the main optimization, so it doesn’t impact solution quality. It impacts latency however.