ordering of end point use

[ivoysey]

right now there's no check that they don't observe before start, or perturb before start, or whatever. these things could cause us to fail tests if the TH is buggy, they think they're perturbed, they haven't and it gets over written some how, and then we act like they haven't.

[ivoysey]

53 is a special case of this where it's really clear what to do: if you have multiple starts, you restart mid-mission, so that's a sufficiently catastrophic event to warrant a runtime check.

[ivoysey]

this table assumes that the arguments that are about to be used in a particular interaction with one of the end points are valid. so remove_obstacle can always be called -- but dynamically you can only actually produce valid arguments if place_obstacle has succeeded at least once.

• [ ] right now, remove_obstacle will produce the same error on all bogus input. the method inside gazebo_interface returns a boolean not an enum, so we just know that it failed, we don't know why. that makes it hard to check for any preconditions on the arguments. maybe this is OK.

• [ ] questions below

endpoint	possible preconditions
query_path	always fine
start	affine
observe	either "always fine" or "always fine once start gets hit" -- the deadline is bogus until the mission starts, but it will never crash
set_battery	always fine, modulo @cyrus-'s battery model. it's odd to set the battery to be higher than it is; do we want to ban that?
place_obstacle	always fine
remove_obstacle	always fine (implicitly: only after at least one place_obstacle succeeds)
perturb_sensor	always fine, modulo joydeep's stuff.

[ivoysey]

• [ ] currently observe will now have "None" as the deadline if they hit it before start. we need to decide if that's the right thing, or if it should th_error() if it's hit out of order, or what.

[ivoysey]

talking to @schmerl today, we decided that it wasn't worth dynamically checking and enforcing this. it amounts to implementing the automaton as actual code, which is a lot of work, and adds a lot more state to the nominally stateless REST API.

choosing to not do that makes our implementation more brittle, and forensics harder if we need to figure out why we're failing tests and the answer is that either the MIT/LL TH or our mini-TH is calling things out of order, but such is life.

if that becomes really bad, we can add more info messages to logging to effectively write our own version of the test history as we observe it.