We use RouteXL to optimise truck routes through the tour endpoint (parameters: type=smalltruck, speed=100, directions=true; no skipOptimisation).
Since 1 November, and much more often today (10 November), some optimisation responses come back with feasible=true and the correct count, but the route is wrong: one stop is repeated several times and other stops are missing. All coordinates we send are distinct. It happens on several different routes.
Example from 10 November, a route with 10 locations: one stop came back 5 times and 3 stops were missing. Response ids with this problem:
4A7wGMy14g8dH56AJrqw, CDR9GK6k1IL425OhvEt4, IGAjqdodnN462s10Q8wF, 7Sc81V8JwHN61HzhTVOd, da18wj6K6U9HV7b9vKvf, Mnpgz76L7FMxiAqQylkF
The identical request returned a correct route at 08:30 (VmmF3zS5S68PuR6T9I6s) and a wrong one at 08:26 and 08:38.
We reproduced it outside our application by sending that same request 50 times, one at a time: 40 responses were wrong, always with the same stops missing, in streaks of bad and good responses.
Could you check this and tell us if it is a known issue? We can send the full request and a wrong response if needed.
We’ve seen a similar issue, it may be related to a system upgrade we were forced to implement. If you can share your request and the result, we’ll check in more detail. If you do not want to share your data here, feel free to email us directly at info@routexl.com
We are seeing the same problem since this morning (10 November) on POST /tour, API v2, with skipOptimisation = 0, type = smalltruck and speed = 100.
The response has status 200, feasible = true and the correct count, but one location is returned several times and other locations are missing. All locations in our requests have a unique name and distinct coordinates.
Figures from our logs:
2 to 9 November: 235 optimisation requests, none with a repeated location
10 November: 34 out of 44, the first at 10:20 and the most recent at 11:37 (CET)
Requests with skipOptimisation = 1 come back correctly
An identical request gave a wrong route at 10:28:13 (response id CueBG226n230qXL4E13w) and a correct one 13 seconds later (ZyEJB9N7Udzd2e6P7kQ0)
Other affected response ids: xRoT2wls7TlK5Mc12DD0, BDeJ9j5G080qE684hn7b, nVo9AmWeMYyorg3r0Y77.
We have sent the full requests and responses to info@routexl.com, because they contain customer addresses. Is there any news on the cause or on when a fix can be expected?
The problem seems to be one of our dedicated servers where the algorithm runs. We’ve taken that specific system out of production, which seems to solve the problem client-side. We’ve also added an additional check on the other servers.
We’ve not yet finally determined the cause but it seems a configuration and/or hardware issue. We’ll continue to work on that, to solve the problem and prevent it from happening again in future.