Less anxiety-inducing return values #771
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Currently, the
Vm::get()
andVm::state_watcher()
methods return aResult<{something}, VmError>
. This means that they can return anyVmError
variant, but the current implementation of these methods willonly ever return
VmError::NotCreated
.This gave me a bit of anxiety when I noticed that we were presently
handling the
VmError::WaitingForInit
variant identically toNotCreated
, which seemed wrong as it implied that we could,potentially, return an error code indicating that no instance has ever
been ensured when in fact, one has been ensured but is still being
initialized. I freaked out about this a bit here:
oxidecomputer/omicron#6726 (comment)
It turns out the current behavior is actually fine, since if the VM is
still initializing, we still allow accessing it and just return a
Starting
state, which is correct. But the type signatures of thesefunctions allow them to return any of these errors, and forces their
callers to handle those errors, and that's the part we were doing
somewhat incorrectly (although, again, in practice it doesn't matter).
Commit 81de422 changes those functions to return an
Option
rather thana
Result
. Now, we returnNone
if no VM has ever been created, makingthat the only error case that callers have to handle. There's no
longer any risk of the HTTP API handlers accidentally returning a "VM
never ensured" error when the VM is ensured-but-initializing. Also, we
can remove the
NotCreated
variant, since it's now no longer returnedanywhere.
Also, I noticed that the
PUT /instance/state
API route would return aNoInstance
error when trying to change the state returned aVmError::WaitingToInitialize
, which seemed potentially bad: this wouldresult in a sled-agent that tries to send a state change request to a
still-initializing VM to believe it's Permanently Gone, and mark it as
Failed
, tear down the zone, and so on. Which seems rude of it!I don't think this is likely to be a problem in practice since, IIRC,
both sled-agent and Nexus will not try to send state change requests to
instances that they understand to be still initializing, but it seemed
good to not return the INSTANCE IS PERMANENTLY GONE error code here.
Therefore, commit ce6bb51 changes this to return a 503, so the
sled-agent will just know it needs to wait for a bit.