Skip to content

Conversation

@FelixSelter
Copy link

@FelixSelter FelixSelter commented Feb 8, 2026

Issue: #427

Changes made:

  • comment on the ty_domain property of ServiceInfo
  • docstring of ServiceInfo::new
  • module docstring of the lib in the examples that informs them about the limitation and guides them to the example where a monitor connection is set up
  • changed logging for this from debug to error so it can be found and because this is a user error that prevents the lib from working as intended

Changes not made but possible if desired:

  • Add a deprecation to the ServiceInfo::new so users are forced to review the message and silence manually with #[allow(deprecated)]

Added two comments to explain the limitation and that the lib will silently fail without a monitor connection
- Added a comment to the ty_domain property of ServiceInfo
- Added a bold portion in the docstring of new
If this fails no service will be published and the library is not working as intended by the user
therefore this should be a hard error.
There are a ton of logs and with debug it seemed unimportant and was near impossible to find for users without experience of this crate
Copy link
Owner

@keepsimple1 keepsimple1 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Overall looks good! Thanks for your PR! A couple of comments inline.

//! // Browse for a service type.
//! // ❗ Make sure that the service name: "mdns-sd-my-test" is <= 15 characters or this will silently fail
//! // You may also want to setup a monitor connection via `mdns.monitor` and log any `DaemonEvent::Error`
//! // You can see how to setup this inside the register example
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think we need to add this doc comment for browse as in this case the service name is provided for the caller, not decided by the caller.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes agreed. I thought that as well but I was unsure what happens if someone overwrites the max length and publishes a service with more than 15 chars. Will that be found by browse or will it fail?

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes it will be found by browse.

//! let mdns = ServiceDaemon::new().expect("Failed to create daemon");
//!
//! // Create a service info.
//! // ❗ Make sure that the service name: "mdns-sd-my-test" is <= 15 characters or this will silently fail
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nitpick: as we do allow the change of the limit via set_service_name_len_max, we should probably say "no longer than the max length limit (15 characters by default)".

// Check the service name length.
if let Err(e) = check_service_name_length(info.get_type(), self.service_name_len_max) {
debug!("check_service_name_length: {}", &e);
error!("check_service_name_length: {}", &e);
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍 Thinking about this more, I tend to agree that it's valid to log it as error because this is truly a case of failure.

/// "_my-service._udp.local.".
/// With default settings service name length must be <= 15 bytes
/// so "_abcdefghijklmno._udp.local." would be valid but "_abcdefghijklmnop._udp.local." is not
/// ❗ **This will silently fail and no error will be shown** unless you setup a monitor connection via `ServiceDaemon::monitor()`
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Now we have an error level log, this can be updated.

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.

2 participants