Confusing UX when using address_for_port on a container that's crashed
#482
Assignees
Labels
Comments
This was referenced Aug 17, 2023
This was
linked to
pull requests
Aug 17, 2023
edmorley
added a commit
that referenced
this issue
Aug 17, 2023
Since: - There was already duplication of formatting stderr/stdout output, which was otherwise going to get worse after #636. - It may also be useful for end users when debugging, to save them having to manually print both stderr and stdout manually. Prep for #482. GUS-W-13966399.
edmorley
added a commit
that referenced
this issue
Aug 17, 2023
Improves the debugging UX for several `ContainerContext::address_for_port` failure modes. In particular, if containers crash after startup then the container logs are now included in the panic error message, rather than only the potentially confusing "No public port X published" message from Docker. Fixes #482. GUS-W-13966399.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Currently, if a container started using
TestContext::start_containercrashes, whenContainerContext::address_for_portis used, it returnsNone- which means the typical.unwrap()call on the return value fails with a "Unwrapping None value" type error, which isn't very descriptive.The fix for this might end up being related to #446 (ie: for long running containers, at least check they are still running before handing over control to the context), or else we could make the return type of
ContainerContextbe aResultwhere the error variant has a more descriptive message ("is this the correct port, or could the server have crashed?" etc).As a workaround, I added
assert_empty!(container.logs_now().stderr)type usages prior to theaddress_for_portcall, to ensure any crash error messages cause an earlier (and easier to debug) failure than theaddress_for_portNone unwrap.GUS-W-13966399.
The text was updated successfully, but these errors were encountered: