Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
aaronchongth opened this issue Sep 7, 2022 · 0 comments
Labels
bug Something isn't working

Comments

@aaronchongth
Copy link
Member

Mentioned here: #16 (comment)

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.

@aaronchongth aaronchongth added the bug Something isn't working label Sep 7, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

1 participant