Skip to content

fix: preserve announcements after excluded address changes - #507

Open
Twister915 wants to merge 1 commit into
keepsimple1:mainfrom
Twister915:codex/preserve-announcement-excluded-addresses
Open

Twister915 wants to merge 1 commit into
keepsimple1:mainfrom
Twister915:codex/preserve-announcement-excluded-addresses

Conversation

@Twister915

@Twister915 Twister915 commented Sep 15, 2026

Copy link
Copy Markdown

Hello! I am submitting three fixes to bugs I encountered while developing a tvOS app for myself.

As far as I understand it, this fixes the third bug I encountered- when my Mac Studio (hosting a service) changed it's IPv6 address for privacy reasons (a macOS feature), my service appeared no longer available from my application.

After reviewing this patch myself, it looks as if the fix is pretty simple: skip updates about unsupported addresses (in my case, IPv6 addresses).

Happy to work with you through any review notes! Everything below this line is pure AI (gpt-6 astra)-


An auto-address service can stop answering discovery queries indefinitely after an address excluded by its policy appears on an existing interface. For example, an IPv4-only service is announced, then IPv6 privacy-address rotation adds a new address on the same interface.

insert_ipaddr rejects that address, but add_interface still attempts an announcement through the new address's socket family. No eligible records exist, so the attempt returns false and the shared per-interface status becomes Probing. No probes were created to restore Announced; query handling then skips the service.

Skip service updates for unsupported addresses, using the same predicate as automatic address insertion. Other services and the daemon's interface tracking continue to process the new address normally.

The regression registers a real service, completes its probes, verifies it is announced, then injects an excluded address into daemon state. It covers IPv4-only and IPv6-only policies using loopback and a private port; it does not change host network configuration. Reverting the fix makes the final assertion fail with Probing instead of Announced.

Validation

  • macOS, nightly Rust: targeted regression passes; fails with the implementation fix removed.
  • cargo fmt --check, async-only build, and all-feature documentation with warnings denied pass.
  • All-feature library suite: 56 passed; test_hostname_resolution_address_removed failed. The same test fails on untouched upstream 75d1941 on this host.
  • Strict nightly Clippy reports existing upstream diagnostics; comparison against the untouched base found no new diagnostics from this change.

This is one independent commit on current upstream main; no other PR is required.

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant