Update from 0.17.1 to 0.17.2 has broken discovery for me

[andrewdavidmackenzie]

I haven't had the chance to debug this in detail yet, but wanted to mention ASAP.

Dependabot created this PR for me to update from 0.17.1 to 0.17.2 here:
andrewdavidmackenzie/pigg#1169

But this has broken discovery in this app. The mdns hw_tests I do in CI fail, and testing interactvely via the piggui GUI also doesn't discover the devices. They show using the discovery tool (macos) and if I switch branches all works again as before.

When I get a moment I will try to debug the issue and come back with more specific info, but I wanted to mention incase there was some known issue, and to highlight to you that "something broek" :-)

This is running on a Mac-mini, ARM64, macOS Tahoe 26.0

[keepsimple1]

Thanks for reporting this issue! Sorry about that. The changes in 0.17.2 (vs 0.17.1) are really small. The only change of the production code is PR #414 . But the reuseport feature is still enabled by default, I'm trying to think how it would break things. If you could have more details, or enable debug logs from mdns-sd, that will very helpful.

reference: all diffs between 0.17.1 and 0.17.2

[andrewdavidmackenzie]

I use this line in Cargo.toml ``` mdns-sd = { version = "0.17.1", default-features = false, features = ["async"], optional = true } ``` So maybe using `default-features=false` disabled the `reuseport` feature and that broke it? Does that mean (on macOS) that `reuseport` is a must for it to work?

[andrewdavidmackenzie]

I added the reuseport feature to my Cargo.toml and that seems to have fixed it.
But I would question "can it work without that feature (on macOS)?"
If not, then maybe a candidate to have that "hardcoded", at least on macOS?

[keepsimple1]

Yes I think macOS needs reuseport. I'm thinking maybe we should have implemented this new feature invert, i.e. instead of a feature of reuseport that is default on, we could have a feature of no_reuseport that is default off.

Let me see if we change it.

[keepsimple1]

I've created a PR #430 to address this issue. Please let me know that works for you.

@Hanssen0 I've missed that #414 actually is not fully backward compatible. Could you please also take a look at #430 if you have time , which would require you change your Cargo.toml to disable reuseport. Thanks!

[Hanssen0]

@Hanssen0 I've missed that #414 actually is not fully backward compatible. Could you please also take a look at #430 if you have time , which would require you change your Cargo.toml to disable reuseport. Thanks!

Sorry for the miscommunication! I actually made some investigations before about if we should make this feature enable_reuseport or disable_reuseport. Here's the reference from The Cargo Book

A consequence of this is that features should be additive. That is, enabling a feature should not disable functionality, and it should usually be safe to enable any combination of features. A feature should not introduce a SemVer-incompatible change.

But yes, I understand about your backward compatibility consideration. I'm fine with #430. But considering that we are still at the 0.y.z stage, a breaking change seems more reasonable for me to make it conform to the Rust paradigm.

4. Major version zero (0.y.z) is for initial development. Anything MAY change at any time. The public API SHOULD NOT be considered stable.

Once again, I apologise for not mentioning that this could have led to a breaking change.

[keepsimple1]

I actually made some investigations before about if we should make this feature enable_reuseport or disable_reuseport. Here's the reference from The Cargo Book

No worries, thanks for the link! I've learned new things!

a breaking change seems more reasonable for me to make it conform to the Rust paradigm.

I think you have a point. Let me consider a bit more about this trade-off.

[keepsimple1]

Looks like none of the approaches (using cargo feature) is perfect:

• With reuseport feature, existing users have to be aware of it and make a change if they were using default_features = false.
• With no_reuseport feature, it is not following additive guideline. In a dependency tree of two references to mdns-sd, one reference using this feature, and another reference not using this feature, the final result would be using this feature and remove reuseport for all reference, which might break the final program.

I am thinking, maybe we should step back and not to use cargo feature at all? Just "silently ignore the error and then continue" like you also mentioned in the original issue report #413 @Hanssen0 ? Thoughts?

EDIT: we can log the error in debug level .
EDIT2: I've updated the diff in #430 to reflect the above thinking.

[andrewdavidmackenzie]

What about: - making reuse port feature essentially empty (if required for backwards compatibility) or at least on platforms that require this in order to work - make that code platform dependant, so on platforms like macos where it's needed to work at all, it is always there no matter what features are enabled?

…

On Sun, Feb 8, 2026, 8:43 PM keepsimple1 ***@***.***> wrote: *keepsimple1* left a comment (keepsimple1/mdns-sd#428) <#428 (comment)> Looks like none of the approaches (using cargo feature) is perfect: - With reuseport feature, existing users have to be aware of it and make a change if they were using default_features = false. - With no_reuseport feature, it is not following additive guideline. In a dependency tree of two references to mdns-sd, one reference using this feature, and another reference not using this feature, the final result would be using this feature and remove reuseport for all reference, which might break the final program. I am thinking, maybe we should step back and not to use cargo feature at all? Just "silently ignore the error and then continue" like you also mentioned in the original issue report #413 <#413> @Hanssen0 <https://github.com/Hanssen0> ? Thoughts? — Reply to this email directly, view it on GitHub <#428 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABKF4LCNRULJZFYZRNU5W7T4K6GW5AVCNFSM6AAAAACUDHBCKOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTQNRYGA3TKNRSHA> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[Hanssen0]

I am thinking, maybe we should step back and not to use cargo feature at all? Just "silently ignore the error and then continue" like you also mentioned in the original issue report #413 @Hanssen0 ? Thoughts?

EDIT: we can log the error in debug level .
EDIT2: I've updated the diff in #430 to reflect the above thinking.

LGTM.

By this approach, maybe we can have an ignore_reuseport_error or similar feature. This sounds like an additive 🤣.

[keepsimple1]

• making reuse port feature essentially empty (if required for backwards
  compatibility) or at least on platforms that require this in order to work

That's basically inline with what I thought too, i.e. removing this feature. I plan the next release as v0.18.0, so it's okay to have breaking changes (again ;-))

• make that code platform dependant, so on platforms like macos where it's needed to work at all, it is always there no matter what features are enabled?

That's what the code was originally: on Unix (i.e. macOS and Linux) platforms we always have it. But the version difference in a platform is tricky and cannot be detected via #cfg AFAIK. Hence we got into this issue.

With all that, I think I'll go with "ignore and log the error, and move on", and removing the feature.

[keepsimple1]

LGTM.

Thanks!

By this approach, maybe we can have an ignore_reuseport_error or similar feature. This sounds like an additive 🤣.

I hear you, but I want to keep things as simple as possible, so I think as long as the code would work on Linux kernels < 3.9, we are solving the original problem. We should be good ;-)

[keepsimple1]

PR merged. Will be in the next release 0.18.0 that has breaking changes.