We have an issue with a specific Stuart Job. On our Delivery WebApp (https://delivery.enriquetomas.com/), a client made an order at 19:32h the Setember 10th. At 19:33h our Store team started to manage the order and passed to “In process” state. In this process we call to the Stuart API to make the Auth, validate the Address and finally create the Job. All these three actions were performed correctly, and the Job ID is 12800431 . But the rider didn’t come immediately. In fact the rider arrived at our store at 21:15h, and finally to our customer’s delivery point at 21:33h. The Stuart API didn’t gave us any error, still, the webhooks were called as the package was picked up at 20:11h and delivered at 21:12h… really strange. Can we talk about this issue and try to figure out what happened?
I can see that this job expired three times and our support relaunched the job each time to continue searching for a driver. Receiving the job ‘expired’ status means that no driver was found within the 20 minute expiration interval set for your account. In this case, our support relaunching the job lead to this long delay between the time that this instant job was created and the time that the driver picked up the package.
To avoid this case from happening you can cancel the job through our cancel a job endpoint upon receiving the job ‘expired’ status. You can then decide whether to send another job creation request or prehaps at this stage the job is no longer relevant for you.
The good news here is that this issue you have encountered will very soon be no more. We are currently rolling out a new architecture at Stuart which is scheduled to be rolled out in Barcelona In the coming week. In this new architecture our support won’t be able to relaunch your expired jobs when you have an expiration interval set on your account (which you do, it’s 20 minutes). For more information on our new architecture and the change it brings to how expirations work please see this announcement.