mirror of
https://github.com/home-assistant/supervisor.git
synced 2026-05-21 23:28:54 +01:00
Stefan Agner
4938fb215d
Triaging SUPERVISOR-1JWK turned up a missed port conflict: RE_PORT_CONFLICT_ERROR only matched one of the Docker daemon's port-in-use message shapes. The two variants produced by current moby — "Bind for <ip>:<port> failed: port is already allocated" from portallocator and "failed to bind host port <ip>:<port>/<proto>: address already in use" from osallocator — fell through to DockerAPIError, got re-raised as AppUnknownError, and the watchdog shipped them to Sentry as unknown errors. Widen the regex to match all known shapes (including the older form embedding the container endpoint, still observed from older daemons and wrappers), anchored on the "failed to set up container networking" prefix and one of the "address already in use" or "port is already allocated" suffixes. Log the raw Docker message at debug level before converting, so curious users can still see the exact upstream text (host IP, container endpoint, protocol) when investigating which process is holding the port. The watchdog's _restart_after_problem now catches AppPortConflict explicitly ahead of the generic AppsError handler: log a warning, break the retry loop, do not call async_capture_exception. A port conflict is an environment condition — another process grabbed the port while the add-on was down — so retrying cannot make it succeed and reporting to Sentry is noise. With port conflicts now raised as typed APIError subclasses at the detection site, the DockerAPIError → format_message() rewrite fallback in api_return_error has no work left. Drop the fallback and delete supervisor/utils/log_format.py along with its tests; the module only ever handled port-conflict prose. Fixes SUPERVISOR-1JWK Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>