fix: avoid panics when checking container state and container.raw is nil #635
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.
What does this PR do?
This PR is fixing how the container State function is handling errors when an edge case takes place. We checked that the raw representation of the container is used internally in the State function, returning it when an error is raised by the Docker client when inspecting a container.
An easy way to reproduce the error described in #540 is to proceed as the test we are adding in this PR: 1) creating a container, 2) terminate it, 3) call container.State function
We noticed the error handling was incorrect in that case when a user calls the State function after termination: it's weird to do so, but the library should protect users for commiting this kind of mistakes. Therefore, we are simply checking if the raw representation is NIL before accessing it, which is the reported error: if raw is nil, then we return nil (the same response from Docker), otherwise return the already "cached" raw.State.
We could have simply returned nil, but we decided to reduce the changeset in this PR and maybe elaborate a follow-up PR with a more consistent change, which could be optimizing the Terminate function to clear the raw representation of the container.
Why is it important?
Consistent error handling when a container is removed (using the public API or because the underlying machine kills the container because of lack of resources).
Related issues
Follow-ups
As mentioned above, I recommend revisiting the Terminate function and clean up all the "state" that lives in the container struct, so that any operation accesing the container returns a clean state. This change could lead to a refactor in any access to the raw representation.