You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
docs/task.md:1018-1019.
Publish receiver-facing IPv6 media tickets only where a reachable scoped address can be published safely; retain fail-closed omission for unusable endpoints.
CONSTRAINED BY the 2026-07-16 P2.8 decision: the media-ticket listener is IPv4-only today, and an IPv6-only control endpoint must NOT be accepted while it advertises media the receiver cannot fetch. This bead must change both sides coherently. Also bound by: one absolute deadline per channel operation plus a shorter idle cap, and the Rc transport pinned to its worker.
Files: src/chromecast/, mDNS endpoint selection.
Independent and fleet-completable.
Implementation notes
Resubmit after fix-forward: clippy match_wildcard_for_single_variants resolved by narrowing the IPv4 find() wildcard in pick_lan_bind_address to IpAddr::V6(_). All other changes from the rejected attempt preserved: cast HTTP server publishes IPv6 receiver URL tickets, control endpoint accepts V6 when listener is V6. Locally green: cargo fmt --check, cargo clippy --all-targets -- -D warnings (debug + release), cargo test --all-targets (1709 + 14 pass). Branch: polecat/tr-b5s.
Refinery handoff
Issue: tr-b5s (task, P2)
Source branch: polecat/tr-b5s
Target: main
Rebased on main via Gastown Refinery.
Summary by CodeRabbit
New Features
Chromecast discovery now supports reachable IPv6 control endpoints, including global and unique-local addresses.
IPv4 endpoints are preferred when both IPv4 and IPv6 are available.
Chromecast connections select a network address that can route to the target receiver.
Bug Fixes
Improved handling of unreachable, link-local, loopback, multicast, unspecified, and invalid endpoints.
IPv6 receiver URLs are now formatted correctly.
Clearer warnings are shown when no usable control address is available.
The reason will be displayed to describe this comment to others. Learn more.
Pull Request Overview
This Pull Request is not up to standards due to a critical misalignment between its metadata and the implementation. While the PR title and description specify extensive functional changes to Chromecast media handling (IPv6 support, protocol compatibility, and Rust source modifications), the provided diff contains only a new GitHub Actions workflow configuration. None of the functional logic or fixes described are present in the code.
Additionally, the proposed GitHub Actions workflow contains high-risk issues, including a syntax error in tool authorization that will prevent command execution and the use of mutable tags for third-party actions, which poses a supply chain security risk. These blockers must be addressed by aligning the code with the PR intent and fixing the workflow logic.
About this PR
Critical scope misalignment: The PR description and title specify extensive functional changes to Chromecast media handling, but the actual diff contains only a new GitHub Actions workflow configuration. The logic described is entirely missing from the implementation.
Test suggestions
Verify IPv6 media ticket publishing on reachable scoped addresses
Verify fail-closed behavior for unusable endpoints
Verify rejection of IPv6 control endpoints when the listener is restricted to IPv4
Verify enforcement of channel operation deadlines and idle caps
Verify Rc transport is pinned to the assigned worker
Verify the clippy fix in pick_lan_bind_address logic
Prompt proposal for missing tests
Consider implementing these tests if applicable:
1. Verify IPv6 media ticket publishing on reachable scoped addresses
2. Verify fail-closed behavior for unusable endpoints
3. Verify rejection of IPv6 control endpoints when the listener is restricted to IPv4
4. Verify enforcement of channel operation deadlines and idle caps
5. Verify Rc transport is pinned to the assigned worker
6. Verify the clippy fix in pick_lan_bind_address logic
The reason will be displayed to describe this comment to others. Learn more.
🔴 HIGH RISK
The gh subcommands should be separated by spaces rather than colons. This ensures the action's tool-matching logic correctly identifies and permits the intended CLI commands.
The reason will be displayed to describe this comment to others. Learn more.
🔴 HIGH RISK
Pin the 'anthropics/claude-code-action' to a full 40-character commit SHA to ensure the action is immutable and secure. Using a tag like '@v1' is not safe as tags can be moved to different commits.
Try running the following prompt in your IDE agent:
Search for the latest commit SHA for the tag v1 of the anthropics/claude-code-action repository and update line 26 in .github/workflows/claude-review.yml to use that SHA instead of the tag, appending # v1 as a comment for context.
The reason will be displayed to describe this comment to others. Learn more.
🟡 MEDIUM RISK
The PR title does not match the actual code changes. The title describes a Chromecast IPv6 feature, while the diff adds a GitHub Action for AI code reviews. Please update the title or verify that the correct files are included in this PR.
The reason will be displayed to describe this comment to others. Learn more.
⚪ LOW RISK
Suggestion: The id-token: write permission is not required for this workflow's configuration and should be removed to minimize the scope of the generated GITHUB_TOKEN.
Chromecast discovery now accepts reachable IPv4 and IPv6 control endpoints. Cast HTTP server startup derives a routable local bind address for the selected receiver target, and ChromecastOutput passes that target address through during initialization.
Adds IPv4/IPv6 routability predicates and target-specific kernel routing probes, replaces generic startup with start_for_target, and adds coverage for family and reachability rules.
This PR reworks Chromecast LAN address selection to fall back to IPv6 (pick_lan_bind_address) and teaches discovery.rs to accept an IPv6 control endpoint only when the cast HTTP listener has itself bound IPv6 (cast_listener_binds_ipv6()), gated by the new CAST_LISTENER_BINDS_IPV6 latch. Docs, tests (both unit-level with the new with_listener_binds_ipv6 harness), clippy, and fmt all look clean and the new tests are well-targeted at the stated address-family rules (global unicast, unique-local, link-local/loopback rejection, symmetric-publish gating).
Critical finding (inline comment on src/discovery.rs:825): Tracing the call graph, cast_listener_binds_ipv6() only ever becomes true once CastHttpServer::start() binds an IPv6 socket — and that function is only invoked lazily, from ChromecastOutput::ensure_cast_server (src/audio/chromecast_output.rs:1969), which itself only runs after a Chromecast has already been selected as the active output in the UI. Selecting it from the UI requires it to have already been discovered and published. That creates a circular dependency: on the IPv6-only-LAN scenario this PR is meant to serve, the very first discovery attempt is rejected because the latch starts false, and the latch can never become true because nothing ever gets far enough to start the server. If my read of the call graph is right, the feature is unreachable in its target scenario. I flagged the exact chain and a possible fix direction (start/probe the server eagerly rather than only on selection) inline.
Medium finding (inline comment on src/audio/cast_http_server.rs:359):pick_lan_bind_address's IPv4 branch now does blind first-match interface enumeration (list_afinet_netifas()) instead of the previous routing-table-aware local_ip_address::local_ip() lookup used as a first attempt. On multi-homed hosts (Docker bridges, VPN interfaces, multiple NICs) this could pick a different — possibly wrong — interface than before, since enumeration order isn't route-preference order. Flagged inline to confirm whether this was an intentional simplification.
Smaller/lower-confidence observations (not filed as blocking, for awareness):
CAST_LISTENER_BINDS_IPV6 is a process-lifetime latch that's never reset once the server has bound IPv6. If the host later moves to an IPv4-only network without restarting the app, discovery would still trust cast_listener_binds_ipv6() == true for a listener/bind that may no longer reflect the current network state. Given the server binds once and doesn't appear to rebind on network changes, this is likely low-impact today, but worth a comment if intentional.
advertised_socket_addrs (pre-existing, src/discovery.rs:589) sorts SocketAddr values, and since SocketAddr::V4 sorts before V6 by variant, IPv4 always wins ties deterministically — this is why "prefers IPv4 when both are advertised" holds regardless of mDNS record order. Not a bug, just confirmed it's not incidental.
The is_reachable_ipv6 bitmask logic (2000::/3 global unicast, fc00::/7 unique-local) checks out correctly against the RFC ranges.
No security, unsafe-Rust, or panic-path issues found in the new code beyond the above. Test coverage for the new address-family rules themselves is thorough; the gap is the untested (and I believe untestable-in-isolation, since it spans two files/an app-lifecycle path) startup-ordering issue above.
The reason will be displayed to describe this comment to others. Learn more.
High: IPv6 Chromecast discovery appears to deadlock and can never actually engage.
cast_listener_binds_ipv6() only returns true after CastHttpServer::start() has bound an IPv6 socket. But that function is only invoked lazily from ChromecastOutput::ensure_cast_server (src/audio/chromecast_output.rs:1969-1988), which runs only after a ChromecastOutput has already been constructed for a device the user selected from the UI (src/ui/output_switch.rs:305-312). Selecting a device from the UI in turn requires it to have already been published by discovery (src/ui/discovery_handler.rs).
So for the network this PR targets — an IPv6-only LAN with no usable local IPv4 address — the sequence is:
usable_chromecast_control_address rejects the V6 control endpoint here because the latch is still false (server never started).
The Chromecast is therefore never published to the output selector.
Because it was never published, the user can never select it, so ensure_cast_server/CastHttpServer::start() never runs.
The latch never flips to true, and step 1 rejects forever.
pick_lan_bind_address (src/audio/cast_http_server.rs:359) only falls back to IPv6 when the host has no usable LAN IPv4 address at all, so even a dual-stack Chromecast can't be used to "bootstrap" the latch on a host that itself lacks IPv4 — the very host population this feature is for.
If this reasoning holds, this PR's core promise ("Publish receiver-facing IPv6 media tickets... where a reachable scoped address can be published safely") never fires for the target scenario, since the gate and the thing that sets the gate are mutually dependent on each other. Was CastHttpServer::start() (or at least a bind probe) meant to run eagerly at startup or on first mDNS discovery of any Chromecast, rather than only after output selection? Fix this →
The reason will be displayed to describe this comment to others. Learn more.
Medium: IPv4 selection dropped the routing-table-aware local_ip_address::local_ip() lookup in favor of blind first-match interface enumeration.
Previously (origin/main), CastHttpServer::start() first tried local_ip_address::local_ip(), which asks the OS which local address it would use to reach the default route — a reasonable proxy for "the real LAN interface" on multi-homed hosts (Docker bridges, VPN tun/wg interfaces, multiple physical NICs, etc.), and only fell back to enumerating list_afinet_netifas() when that failed.
This version always goes straight to list_afinet_netifas() and takes the first entry matching the IPv4 predicate (line 360-365). list_afinet_netifas()'s ordering is OS-dependent getifaddrs() order, not route-preference order, so on a host with e.g. both docker0 (172.17.0.1) and eth0 (192.168.1.x), this could now pick the non-routable/wrong interface where the old code would have picked the one the OS actually uses for outbound traffic.
Was this behavior change intentional/acceptable, or should the routing-table-based local_ip() lookup be retained as the first IPv4 attempt (with list_afinet_netifas() used only for the fallback / IPv6 path as before)?
Extend CastHttpServer::start() to prefer a routable IPv4 LAN address and
fall back to a reachable global-unicast or unique-local IPv6 address
when no such IPv4 exists. Scoped and link-local IPv6 addresses remain
rejected because a portable receiver URL cannot carry the required zone
identifier. Selection logic lives in a small pick_lan_bind_address helper
that the new tests exercise deterministically against synthetic candidate
lists. The discovery code's IPv4-only control endpoint contract is
preserved — an IPv6-only receiver is still omitted, fail-closed — so an
IPv6 listener only widens the publishable ticket surface, not what the
receiver will accept.
The bound-once ticket URL formats with SocketAddr::Display, which already
bracketed IPv6, so start_on_ipv6_loopback_formats_a_bracketed_ticket_when_available
and start_on_rejects_scoped_and_link_local_ipv6_addresses remain the
authoritative contract tests for listener binding.
Refinery Gate 1 rejected tr-b5s because the control-endpoint side was
left untouched: only the listener side was extended to publish IPv6
media tickets. On an IPv6-only LAN the listener would bind V6 and serve
tickets to nobody, because every mDNS-resolved control endpoint was
rejected by the IPv4-only usable_chromecast_control_address.
Extend usable_chromecast_control_address to accept a reachable V6
endpoint under the same 2000::/3 or fc00::/7 rule the listener uses,
rejecting link-local, loopback, unspecified, multicast, and port 0.
Gate V6 acceptance on the listener having actually bound an IPv6
socket via a process-global latch set by CastHttpServer::start_on,
so the symmetric-publish guarantee the bead requires cannot be
violated by a listener that still binds V4.
Update the failing-control warn text to reflect both families and
add 7 focused tests covering V6 acceptance under the listener latch,
V6 rejection when the listener is V4, link-local/loopback/unspecified
rejection even when the listener is V6, port-zero V6 rejection,
and the IPv4-preferred behaviour when both families advertise.
The CI clippy pedantic gate rejected this branch because the
`_ => false` wildcard inside pick_lan_bind_address's IPv4
find() only ever catches IpAddr::V6 (the other arm matches V4).
clippy::match_wildcard_for_single_variants fires when a wildcard
covers a single concrete variant; the project's clippy config
treats pedantic+nursery as deny, so the wildcard had to be
replaced with the explicit `IpAddr::V6(_)` arm.
This is a fix-forward on the rejected branch polecat/tr-b5s.
The surrounding change (accepting V6 control endpoints when the
listener is V6) is sound — only the lint was unsound. The sibling
match a few lines below (`_ => None` in the V6 find_map) is
correct as-is: its guarded V6 arm can return Some for some V6
values, so the wildcard still covers more than one variant and
clippy does not flag it.
No behavior change — IpAddr is currently a sum of V4 and V6, so
naming V6 explicitly produces the same fall-through as the
wildcard.
Validated locally: cargo fmt --check clean; cargo clippy
--all-targets -- -D warnings exits 0 on this branch (the same
command that previously exited 101).
…ch (tr-b5s)
The operator rejection called out two compounding bugs in the rejected
attempts to publish IPv6 media tickets:
1. The IPv6 first-device circular dependency: discovery gated V6
control-endpoint acceptance on `cast_listener_binds_ipv6`, which only
flipped after `CastHttpServer::start_on` actually bound a V6 socket.
But `start` was called lazily — only when the user picked a device —
and the user could never pick a V6-only device because discovery had
already filtered it out. The latch could not flip on a V6-only first
discovery, so the device was permanently invisible.
2. Blind first-match interface enumeration in `pick_lan_bind_address`
replaced the original routing-aware `local_ip_address::local_ip()`
selection. On a multihomed/VPN/container host the first enumerated
interface is not necessarily the one that can reach the receiver.
Fix-forward:
- Discovery (`usable_chromecast_control_address`) now accepts any reachable
IPv6 control endpoint based on address validity alone — no listener
latch. The IPv6 first-discovery case is no longer unreachable.
- The `CAST_LISTENER_BINDS_IPV6` latch, its swap helpers, and the
discovery-side `with_listener_binds_ipv6` test lock are removed; they
encoded the circular dependency rather than routing awareness.
- `CastHttpServer::start_for_target(target)` replaces the no-target
`start`. The bind address is selected by asking the kernel which local
address would route to the chosen receiver (UDP connect + local_addr),
with a family-mismatch guard so an unreachable V6 target cannot
silently fall back to V4. `ChromecastOutput` now stores the device
address and passes it through `ensure_cast_server`.
- New tests cover: IPv6-only first discovery, IPv6 acceptance when only
loopback V4 candidates are advertised (multihomed selection coverage),
V6 acceptance gated on reachable-IPv6 predicate, and the routed-local
family-mismatch guard.
- `chromecast_publication_rejects_ipv6_only_when_listener_is_v4` (which
encoded the latch behavior) is replaced with tests that exercise the
new no-latch contract.
Validation: cargo fmt --check, cargo clippy --all-targets -- -D warnings
(debug + release), and cargo test --all-targets all green.
This is a re-review of the current state after commit f795bdb ("routing-aware bind with target, drop V6 listener latch"). Both issues flagged in the prior review round are resolved:
Previously "High: circular dependency made IPv6 discovery unreachable" — now fixed.usable_chromecast_control_address (src/discovery.rs:797) no longer gates IPv6 acceptance on any runtime latch — it accepts a V6 control endpoint purely on address validity (global-unicast 2000::/3 or unique-local fc00::/7, non-loopback, non-link-local, non-multicast, non-zero port), mirrored via the new cast_http_server::is_reachable_ipv6. The old CAST_LISTENER_BINDS_IPV6 latch and cast_listener_binds_ipv6() are gone entirely (confirmed via grep — no remaining references). This breaks the deadlock: a device can now be discovered and published on an IPv6-only LAN without the server ever having bound anything first.
Previously "Medium: IPv4 selection dropped routing-table-aware lookup" — now fixed, and improved beyond the original.pick_lan_bind_address and the old local_ip_address::local_ip() call are both gone. In their place, CastHttpServer::start_for_target(target: SocketAddr) (src/audio/cast_http_server.rs:429) uses routing_aware_lan_bind_address_for_target, which opens a UDP socket, connects it to the actual receiver's address, and reads back the local address the kernel selected via getsockname(). This is more precise than the pre-PR behavior — it routes specifically to the chosen Chromecast rather than to an arbitrary external/default-route destination — and correctly handles multihomed/VPN/container hosts for both address families. ChromecastOutput now threads the discovered device's address through as device_address (src/audio/chromecast_output.rs:54) and passes it to start_for_target in ensure_cast_server, so the bind decision is made per-device rather than via any shared/global state.
I traced the full path end-to-end, including code outside this PR's diff, to confirm the fix isn't just locally correct but actually reachable: format!("cast://{address}") (src/discovery.rs:893) relies on SocketAddr's Display impl, which produces bracketed [addr]:port for V6 without a scope id (link-local addresses are already rejected upstream, so no zone identifier ever needs to survive the round trip); src/ui/output_switch.rs:393 parses that same string back via host_port.parse().ok()? into a SocketAddr, which handles bracket notation natively. So a discovered V6-only device really can flow from mDNS → publish → UI selection → ChromecastOutput::new → start_for_target without hitting the old chicken-and-egg problem.
I also checked test isolation: cast_server is a per-ChromecastOutput field (pre-existing, not changed by this PR), so binding a server for one device's address family can't leak into another device's selection.
Remaining observations
Inline comment posted (src/audio/cast_http_server.rs:1736, low severity): routing_aware_lan_bind_address_for_target_picks_the_routed_local_address opens a real UDP socket and asks the kernel to route to 192.0.2.42:8009, then .expect()s a result. This depends on the test runner having a non-loopback interface with a route out — true in this sandbox and presumably true in this repo's CI, but worth a second look if this test ever becomes flaky in a more restricted runner.
Stale dependency (not part of the diff, so no inline comment possible):local-ip-address = "0.6" in Cargo.toml:106 has no remaining callers anywhere in src/ after this PR removes the last usage (confirmed via repo-wide grep). Worth dropping in a follow-up to avoid carrying a dead dependency and its transitive Cargo.lock entries.
No correctness, security, or concurrency issues found in the new code beyond the above. The IPv4/IPv6 predicate split (is_routable_lan_ipv4/is_routable_lan_ipv6 for kernel-selected bind addresses vs. usable_chromecast_control_address for untrusted mDNS-advertised addresses) correctly applies the stricter multicast/broadcast checks only where attacker/malformed input is possible.
Test coverage for the new address-family and routing-selection rules is thorough, including the exact regression scenarios called out in the prior review (first-discovery on an IPv6-only endpoint, loopback-IPv4-masking-IPv6, family preservation).
I was unable to run cargo fmt/clippy/cargo test myself in this environment (blocked by sandbox command approval), so I relied on static reading of the diff plus the PR's own report of a clean local run (cargo fmt --check, cargo clippy --all-targets -- -D warnings, cargo test --all-targets, 1709 + 14 passing).
The reason will be displayed to describe this comment to others. Learn more.
Low: this test depends on real host networking and will panic in a fully offline/loopback-only sandbox.
routing_aware_lan_bind_address_for_target opens a real UdpSocket, binds it, and connect()s to 192.0.2.42:8009 to ask the kernel which local address it would route through. That's a legitimate way to test routing selection, but it means this test's pass/fail depends on the test-runner's network configuration rather than on the code under test: on a host/container with only a loopback interface and no default route (some hardened CI runners, some sandboxes), local_addr() after a UDP "connect" can still succeed even without a real route in some OSes, but on others the initial connect() can fail if there's no route to a non-local destination at all, and .expect(...) here would panic rather than fail as a normal assertion. Worth double-checking this is stable across whatever CI image actually runs cargo test for this repo (e.g., does it always have a non-loopback interface with a default route?) — if there's any chance it doesn't, consider skipping the test when no LAN interface is present rather than asserting Some(..) unconditionally.
Low severity — noting for awareness, not blocking, since the PR states tests are locally green and this environment (and this review sandbox) both did have a real LAN interface.
Add a link-local IPv4 case to this regression test.
This test's rejection list (0.0.0.0, 127.0.0.1, 224.0.0.1, 255.255.255.255) doesn't include a 169.254.x.x address, which is why the missing is_link_local() check above went uncaught.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@src/discovery.rs` around lines 1119 - 1140, The regression test
chromecast_publication_skips_unusable_ipv4_control_endpoints must cover an IPv4
link-local address. Add a 169.254.x.x endpoint to the event’s rejected-address
list and ensure the test still selects 192.0.2.45, also validating that
usable_chromecast_control_address rejects the link-local endpoint.
Routed-IPv4 test assumes an outbound default route.
Unlike the IPv6-loopback test above (which gracefully returns early when the capability is unavailable), this test .expect()s that 192.0.2.42 is routable and panics otherwise. In a fully network-isolated CI sandbox (no default route/interface at all), this could fail unpredictably.
♻️ Suggested graceful skip
fn routing_aware_lan_bind_address_for_target_picks_the_routed_local_address() {
let target: SocketAddr = "192.0.2.42:8009".parse().unwrap();
- let local = routing_aware_lan_bind_address_for_target(target)- .expect("host must have a routable LAN IPv4 reachable to 192.0.2.42");+ let Some(local) = routing_aware_lan_bind_address_for_target(target) else {+ // No outbound IPv4 route available in this environment (e.g. a+ // fully network-isolated sandbox); nothing to assert.+ return;+ };
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@src/audio/cast_http_server.rs` around lines 1721 - 1748, Update
routing_aware_lan_bind_address_for_target_picks_the_routed_local_address to
gracefully skip when routing_aware_lan_bind_address_for_target cannot find a
routable local address, instead of panicking via expect. Preserve the existing
IPv4 validation when the helper succeeds and retain the family-mismatch
assertion.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@src/discovery.rs`:
- Around line 814-835: Update usable_chromecast_control_address so the
SocketAddr::V4 arm also rejects IPv4 link-local addresses via the address API’s
is_link_local check, while preserving the existing port, unspecified, loopback,
multicast, and broadcast validation and the IPv6 behavior.
---
Outside diff comments:
In `@src/discovery.rs`:
- Around line 1119-1140: The regression test
chromecast_publication_skips_unusable_ipv4_control_endpoints must cover an IPv4
link-local address. Add a 169.254.x.x endpoint to the event’s rejected-address
list and ensure the test still selects 192.0.2.45, also validating that
usable_chromecast_control_address rejects the link-local endpoint.
---
Nitpick comments:
In `@src/audio/cast_http_server.rs`:
- Around line 1721-1748: Update
routing_aware_lan_bind_address_for_target_picks_the_routed_local_address to
gracefully skip when routing_aware_lan_bind_address_for_target cannot find a
routable local address, instead of panicking via expect. Preserve the existing
IPv4 validation when the helper succeeds and retain the family-mismatch
assertion.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
Push a commit to this branch (recommended)
Create a new PR with the fixes
ℹ️ Review info⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro Plus
Run ID: a2ad2dfe-3bdb-4bed-ad94-680baca427f1
📥 Commits
Reviewing files that changed from the base of the PR and between 1146637 and f795bdb.
The SocketAddr::V4 arm checks unspecified/loopback/multicast/broadcast but is missing the is_link_local() check that the docstring above (Lines 795-797) and the PR's own stated contract both require ("non-loopback, non-link-local, non-unspecified, non-multicast, non-broadcast"). As written, an advertised APIPA address (169.254.0.0/16) now passes this filter and can be selected as the Chromecast control endpoint, publishing an unreachable cast://169.254.x.x:port URL — and it can win over a genuinely routable candidate if it sorts earlier in the advertised address list.
🐛 Proposed fix
SocketAddr::V4(v4) => {
let ip = *v4.ip();
!ip.is_unspecified()
&& !ip.is_loopback()
+ && !ip.is_link_local()
&& !ip.is_multicast()
&& ip != Ipv4Addr::BROADCAST
}
📝 Committable suggestion
‼️IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@src/discovery.rs` around lines 814 - 835, Update
usable_chromecast_control_address so the SocketAddr::V4 arm also rejects IPv4
link-local addresses via the address API’s is_link_local check, while preserving
the existing port, unspecified, loopback, multicast, and broadcast validation
and the IPv6 behavior.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
![codacy-production[bot]](https://avatars.githubusercontent.com/in/56611?s=60&v=4){kind=small}
![claude[bot]](https://avatars.githubusercontent.com/in/1236702?s=60&v=4){kind=small}
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
Summary
docs/task.md:1018-1019.
Publish receiver-facing IPv6 media tickets only where a reachable scoped address can be published safely; retain fail-closed omission for unusable endpoints.
CONSTRAINED BY the 2026-07-16 P2.8 decision: the media-ticket listener is IPv4-only today, and an IPv6-only control endpoint must NOT be accepted while it advertises media the receiver cannot fetch. This bead must change both sides coherently. Also bound by: one absolute deadline per channel operation plus a shorter idle cap, and the Rc transport pinned to its worker.
Files: src/chromecast/, mDNS endpoint selection.
Independent and fleet-completable.
Implementation notes
Resubmit after fix-forward: clippy match_wildcard_for_single_variants resolved by narrowing the IPv4 find() wildcard in pick_lan_bind_address to IpAddr::V6(_). All other changes from the rejected attempt preserved: cast HTTP server publishes IPv6 receiver URL tickets, control endpoint accepts V6 when listener is V6. Locally green: cargo fmt --check, cargo clippy --all-targets -- -D warnings (debug + release), cargo test --all-targets (1709 + 14 pass). Branch: polecat/tr-b5s.
Refinery handoff
tr-b5s(task, P2)polecat/tr-b5smainmainvia Gastown Refinery.Summary by CodeRabbit
New Features
Bug Fixes