Directions API assigns services during fixed time window breaks! Breaks are broken!

We sometimes use breaks to allow for workers to have fixed split shifts, however - the route optimiser is returning services allocated during these fixed breaks! It’s says the breaks aren’t needed. We aren’t using TimeWindowBreak, not DriveTimeBreak - so what gives?

We actually had to change our code to sanitise your results by removing activities. You can see in the solution JSON file below where we have adapted the solution so it forces back in the break.

Please can you look into this as a matter of urgency? Our customers have been complaining about it and it’s causing us a real problem.

Problem file:

{“services”:[{“id”:“4-17-2023-82-0”,“address”:{“location_id”:“SO30 3GR37”,“lat”:50.9320248,“lon”:-1.3290277},“time_windows”:[{“earliest”:46800,“latest”:55800}],“duration”:1800,“preparation_time”:120,“priority”:4,“disallowed_vehicles”:[]}],“vehicles”:[{“vehicle_id”:“94”,“start_address”:{“location_id”:“SO32 2LZ”,“lat”:50.9327336,“lon”:-1.199307},“earliest_start”:27000,“latest_end”:79200,“max_jobs”:8,“type_id”:“1”,“break”:{“earliest”:46800,“latest”:46800,“duration”:14400}}],“vehicle_types”:[{“type_id”:“1”,“profile”:“car”},{“type_id”:“2”,“profile”:“racingbike”},{“type_id”:“3”,“profile”:“foot”}],“objectives”:[{“type”:“min”,“value”:“completion_time”}]}

Adapted solution

{“copyrights”:[“GraphHopper”,“OpenStreetMap contributors”],“job_id”:“d8bc512f-8271-4f6c-af2e-0d3289e82940”,“status”:“finished”,“waiting_time_in_queue”:0,“processing_time”:84,“solution”:{“costs”:386,“distance”:23912,“time”:1664,“transport_time”:1664,“completion_time”:22434,“max_operation_time”:22434,“waiting_time”:18850,“service_duration”:1800,“preparation_time”:120,“no_vehicles”:1,“no_unassigned”:0,“routes”:[{“vehicle_id”:“94”,“shift_id”:“default-shift”,“distance”:23912,“transport_time”:1664,“completion_time”:22434,“waiting_time”:18850,“service_duration”:1800,“preparation_time”:120,“activities”:{“0”:{“type”:“start”,“location_id”:“SO32 2LZ”,“address”:{“location_id”:“SO32 2LZ”,“lat”:50.9327336,“lon”:-1.199307},“arr_time”:27000,“arr_date_time”:“1970-01-01T08:30:00+01:00”,“end_time”:27000,“end_date_time”:“1970-01-01T08:30:00+01:00”,“waiting_time”:0,“distance”:0,“driving_time”:0,“preparation_time”:0,“load_after”:[0]},“2”:{“type”:“end”,“location_id”:“SO32 2LZ”,“address”:{“location_id”:“SO32 2LZ”,“lat”:50.9327336,“lon”:-1.199307},“arr_time”:49434,“arr_date_time”:“1970-01-01T14:43:54+01:00”,“end_time”:49434,“end_date_time”:“1970-01-01T14:43:54+01:00”,“waiting_time”:0,“distance”:23912,“driving_time”:1664,“preparation_time”:0,“load_before”:[0]}},“bad_activities”:[{“type”:“service”,“id”:“4-17-2023-82-0”,“location_id”:“SO30 3GR37”,“address”:{“location_id”:“SO30 3GR37”,“lat”:50.9320248,“lon”:-1.3290277},“arr_time”:27830,“arr_date_time”:“1970-01-01T08:43:50+01:00”,“end_time”:48600,“end_date_time”:“1970-01-01T14:30:00+01:00”,“waiting_time”:18850,“distance”:11926,“driving_time”:830,“preparation_time”:120,“load_before”:[0],“load_after”:[0]}]}],“unassigned”:{“services”:[“4-17-2023-82-0”],“shipments”:[],“breaks”:[“94_break”],“details”:[{“id”:“94_break”,“code”:24,“reason”:“driver does not need a break”},{“code”:2,“id”:“4-17-2023-82-0”,“reason”:“cannot be visited within time window”}]}}}

Incidently - we adapted the solution by moving activities to a new node bad_activities - just so we can show you what the API actually assigned.