feat(cli): type-free topic echo via /topic#pkg.Msg inference, this mi…

[Nabla7]

Alex was complaining about dimos not having an equivalent to "ros topic echo", so I looked into it and it already did.

However it needed the type name to be passed on so I wrote some code to infer it.

• Make type_name optional in 'dimos topic echo'
• Infer message type from LCM channel suffix (e.g. /odom#nav_msgs.Odometry)
• Dynamically import dimos.msgs. and call cls.lcm_decode(data)
• Keep existing explicit-type mode working
• Update transports.md docs

[greptile-apps]

Greptile Overview

Greptile Summary

This PR adds automatic message type inference to dimos topic echo, allowing users to omit the type name parameter and have it inferred from LCM channel suffixes like /topic#pkg.Msg.

Key Changes:

• Made type_name parameter optional in the CLI command signature
• Added inferred mode that listens to typed LCM channels matching the pattern /topic#pkg.Msg
• Dynamically imports message classes from dimos.msgs.<pkg> and decodes data using cls.lcm_decode()
• Preserved existing explicit-type mode for backwards compatibility
• Updated documentation to explain both modes

How It Works:
When type_name is omitted, the command creates a raw LCM subscriber with a regex pattern to match channels like /odom#nav_msgs.Odometry. When messages arrive, it parses the channel suffix to extract the package and class name, dynamically imports the class, and decodes the raw bytes.

Integration:
The change integrates with the existing LCM transport system and leverages the autoconf() function to ensure proper LCM system configuration before subscribing.

Confidence Score: 2/5

• Not safe to merge - contains critical error handling gaps that will cause runtime crashes
• The implementation has multiple unhandled error conditions in the message parsing and decoding path (lines 77-81). These will cause the CLI tool to crash with unhandled exceptions when encountering malformed channel names, missing packages, or corrupted data. The split operations assume specific formats without validation, and import/decode operations lack try-except blocks.
• dimos/robot/cli/topic.py - The on_msg callback function needs comprehensive error handling to prevent crashes during message processing

Important Files Changed

File Analysis

Filename	Score	Overview
dimos/robot/cli/dimos.py	5/5	Made type_name parameter optional with updated help text for type inference feature
dimos/robot/cli/topic.py	2/5	Added type inference mode with regex-based channel pattern matching and dynamic message decoding, but missing error handling for malformed channels and failed imports
docs/concepts/transports.md	5/5	Added documentation for CLI commands including new type-free topic echo

Sequence Diagram

sequenceDiagram
    participant User
    participant CLI as dimos topic echo
    participant LCM as LCM Listener
    participant Module as dimos.msgs.*
    
    User->>CLI: dimos topic echo /odom
    CLI->>CLI: Check type_name is None
    CLI->>CLI: Call autoconf()
    CLI->>LCM: Subscribe to pattern ^/odom#.*
    CLI->>User: "Listening on /odom..."
    
    loop Message arrives
        LCM->>CLI: on_msg(channel="/odom#nav_msgs.Odometry", data)
        CLI->>CLI: Split channel by "#"
        CLI->>CLI: Split msg_name by "."
        CLI->>Module: importlib.import_module("dimos.msgs.nav_msgs")
        Module-->>CLI: nav_msgs module
        CLI->>Module: getattr(module, "Odometry")
        Module-->>CLI: Odometry class
        CLI->>Module: Odometry.lcm_decode(data)
        Module-->>CLI: decoded message
        CLI->>User: print(message)
    end

Loading

[greptile-apps]

_{5 files reviewed, 5 comments}

_{Edit Code Review Agent Settings | Greptile}

[greptile-apps]

[P0] Missing error handling for channel parsing and message decoding. If a channel doesn't contain # or ., or if the package/class doesn't exist, this will crash with an unhandled exception. The callback should catch exceptions and print error messages instead of crashing the listening loop.

Triggering conditions: malformed channel names, missing message packages, or corrupted message data.

[greptile-apps]

[P1] If channel doesn't contain #, split will return only one element, causing ValueError: not enough values to unpack on the unpacking. Consider validating the channel format or using try-except.

[greptile-apps]

[P1] If msg_name doesn't contain ., split will return only one element, causing ValueError: not enough values to unpack. This happens if someone publishes to a channel like /topic#BadFormat without the package prefix.

[greptile-apps]

[P2] No error handling for import failures or missing attributes. If the package doesn't exist in dimos.msgs or the class doesn't exist in the module, this will raise ModuleNotFoundError or AttributeError.

[greptile-apps]

[P3] The regex pattern ^{topic}#.* will match channels that start with the topic but could match unintended channels if the topic is a prefix of another topic. For example, if topic is /odom, it will also match /odom_extended#pkg.Msg. Consider using ^{topic}#[^#]+$ to be more precise.

[leshy]

looks good tnx!