search

open-rmf / fleet_adapter_mir

RMF/RoMi-H fleet adapter for the MiR API
Apache License 2.0
15 stars 15 forks source link

Potential race condition when REST calls are not guaranteed to complete in order #20

Open aaronchongth opened 2 years ago

aaronchongth commented 2 years ago

Mentioned here: https://github.com/osrf/fleet_adapter_mir/pull/16#issuecomment-1238407185

On this line and this line we're looking at the state reported by MiR, and if it gives us a READY result then we assume that it has reached the last waypoint that we commanded to it.

However, what happens if the system falls out of sync? For example, what if the following sequence happens:

  • fleet adapter sends mission request,
  • fleet adapter requests task state
  • MiR receives task state request and issues response that the robot is Ready
  • MiR receives mission request
  • fleet adapter receives confirmation of mission request
  • fleet adapter receives response that robot is Ready, which is taken to mean that the last mission request has already succeeded

This sequence may be improbable, but unless there's something in the REST API library to guarantee that the REST request/response ordering is FIFO, we have to consider that this sequence is possible. Packets dropping over wifi with TCP resending the requests + responses could allow this sequence to happen. I've certainly witnessed this kind of behavior in async systems that don't have message ordering guarantees.