Remove monitored container causes 404 error

[ualex73]

If a monitored container is removed with e.g. "docker rm", stats will not work properly.

The logging says:
2019-08-17 06:59:13 INFO (DockerContainerStats) [custom_components.docker_monitor.helpers] Stats runner
2019-08-17 06:59:13 INFO (DockerContainerStats) [custom_components.docker_monitor.helpers] Cannot get get container
2019-08-17 06:59:13 DEBUG (DockerContainerStats) [custom_components.docker_monitor.helpers] Request exception: 404 Client Error: Not Found ("No such container: ssh")
2019-08-17 06:59:13 INFO (DockerContainerStats) [custom_components.docker_monitor.helpers] Cannot get docker container
2019-08-17 06:59:13 DEBUG (DockerContainerStats) [custom_components.docker_monitor.helpers] Request exception: Cannot request container info

I know it is self inflicted, but we should try to handle it nicer ;-)

[Sanderhuisman]

I will look in this one, I think it is already handled well, but this is the logging output when this case happens.

Edit;
in the helpers file line 303-305 (latest version of develop branch)

            except Exception as ex:
                _LOGGER.info("Cannot get docker container")
                _LOGGER.debug("Request exception: {}".format(ex))

[ualex73]

I enabled a backtrace, and the code which gives it is the following one:

    def _reload_container(self):
        try:
            if not self._container:
                self._container = self._client.containers.get(self._name)
            self._container.reload()
        except Exception as ex:
            self._container = None
            _LOGGER.info("Cannot get get container")
            _LOGGER.debug("Request exception: {}".format(ex))
            raise ConnectionError("Cannot request container info")

The "raise" gives it back to the caller, so the following for-loop ends too:

for name, container in self._api._containers.items():

[Sanderhuisman]

Ah I see, I made a fix in pull request #15

[ualex73]

The "exc_info=True" in the _LOGGER.xxx('...', exc_info=True) was handy here ... Could be handy thing for troubleshooting, if we add it in real error scenarios (which normally shouldn't happen)

[Sanderhuisman]

True, but it will spam the log file. With the current trace it is possible to trace the location and extra traces if necessary ;)

You are keeping me busy! 😜

[ualex73]

Isn't the plan, but happy to help to make it more robust 👍