My first attempt as been to rewrite TopicId::default_parent_identifier along the following lines:

    /// Returns the topic identifier of the parent of an entity
    pub fn default_parent_identifier(&self) -> Option<Self> {
        match self.0.split('/').collect::<Vec<&str>>()[..] {
            ["device", "main", "", ""] => None,
            ["device", _, "", ""] => Some("main"),
            ["device", parent_id, "service", _] => Some(parent_id),
            _ => None,
        }
        .map(|parent_id| EntityTopicId(format!("device/{parent_id}//")))
    }

Indeed the current behavior of this function is weird (the parent of a child device is the child itself) and doesn't match is doc comment.

However, my proposal matches the doc comment but makes fail 35 unit tests!

@albinsuresh any idea on why this is not the correct way to fix this issue?

Yeah, the current impl of default_parent_identifier seems wrong as it implies that the parent of device/child1// is child1 which doesn't make any sense. That logic only applies to service entities following the default topic scheme. So, the new function that you've added is correct and named appropriately. I'd drop the old one in favour of the new one.

Regarding the test failures (I looked at some, not all), it's coming from the auto-registration logic that tries to auto-register device/child1// entity when a message like te/device/child1///m/temp is received. That auto-registration logic relies on the same default_parent_identifier function to extract the source entity topic id from the incoming message topic. In this case, they're not looking for the "parent", but the "source" entity itself. So, the current default_parent_identifier function can be renamed to default_source_entity_identifier to better reflect that logic. The newly added function can be used to extract the "parent" of a "service" as done in this PR.

In this case, they're not looking for the "parent", but the "source" entity itself.

That's really confusing but is aligned with the code (returning self for child devices and the parent for a service).

=> I will fix the name and the doc comment.

=> I will fix the name and the doc comment.

Done: c24e633

Here I do think the test should fail ... but it doesn't.

Indeed, 'te/device/child2/service/foo' '{"@type":"child-device"}' registers a child device on a service topic.

@albinsuresh Is this expected or a side effect of auto-registration?

Though shouldn't auto registration only kick in if you are not registration something...here it is explicitly registering a given type, so there is no need to try to auto detect anything.

Indeed, this is what happens: no auto registration kicks in. That's a just bit confusing because applied on a topic matching auto registration requirements.

Yes @reubenmiller is right. Auto-registration kicks in only when the source entity for a message isn't explicitly registered up-front. But, since there is an explicit registration happening here, it just doesn't kick in. In fact we advise the users to disable auto-registration if they decide to use explicit registration for any entities.

We don't prevent the users from re-using the default topic scheme while doing explicit registrations either, but yeah it can result in such unexpected/uncommon usages as well. Not sure if we should completely prevent it, as the default topic scheme still provides a starting point/guidance.