GV

GeezerVison

The World Wide Web, restored to 800 pixels of glory.

Home|About|Gaming cabinet|Archives|How it works|Starter sites

On this site

  • Sign in
  • ActionsCI/CD and automation
  • CodespacesCloud development environments
  • All Features
  • Documentation
  • Training
  • Certifications
  • Build with Copilot
  • Customize Copilot
  • Integrations
  • Trending repos
  • GitHub Sponsors
  • Developer articles
  • Enterprises

This view

  • Original page
  • New address

GeezerVison is showing github.com — async_update_interfaces does not report whether the requested interfaces were bound · Issue #1916 · python-zeroconf/python-zeroconf

async_update_interfaces does not report whether the requested interfaces were bound #1916

New issue
Copy link
New issue
Copy link
Open
#1946
Open
async_update_interfaces does not report whether the requested interfaces were bound#1916
#1946
Copy link

Description

@bdraco
bdraco
opened on Sep 28, 2026
Issue body actions

Problem

Zeroconf.async_update_interfaces is best-effort and returns None, so a caller cannot tell whether the requested configuration was applied.

Two failure paths are logged and swallowed:

  • A listen socket rebuild that fails, for example switching an IPv4 instance to IPVersion.All on a host that cannot open a dual-stack AF_INET6 socket. The engine logs Skipping interface update; listen socket rebuild failed and returns False.
  • A requested interface that fails to bind. The engine logs Interface ... not added once and carries on.

In both cases Zeroconf.async_update_interfaces still commits the requested interfaces and ip_version as the retained configuration, and returns normally.

Where

  • Engine rebuild failure returns False, the same value as "nothing was added".
  • _async_add_interface returns False for an interface that did not come up.
  • Zeroconf.async_update_interfaces uses the engine's result only to decide whether to re-announce.

Why it matters

A caller that asks for dual-stack and cannot get it has no signal to fall back to IPVersion.V4Only, or to retry later. It also cannot log an accurate outcome: a caller that logs "reconciled with IPVersion.All" after a swallowed rebuild failure is wrong.

In esphome/device-builder#2864 this meant a runtime IPv4-only fallback could not be implemented, because the failure it would react to never surfaces.

Suggested fix

Report the outcome from the public method. Options:

  • Return whether the desired interface set fully bound, or the list of interfaces that were skipped.
  • Raise when the address family rebuild fails, since in that case none of the requested change was applied.

Either keeps the best-effort behaviour for per-interface failures while letting callers react.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions

      You are visitor 01402520 — GeezerVison does not store the pages you look up.
      Best viewed with Netscape Navigator 4.7 or Internet Explorer 6 at 800×600. No cookies required.