Recording bag with message compression not implemented

[audrow]

Description

When I try to record a bag with the compression mode zstd and format message, the bag closes with an error after the first message.

Expected Behavior

I expect to be able to record a bag with the following command:

ros2 bag record --compression-format zstd --compression-mode message -a

Actual Behavior

I can start a bag recording with the above command, but seemingly as soon as a message is sent, the recording stops with a Not implemented error. Here is the printout:

After starting recording, but before a message is sent:

[INFO] [1589572027.398596947] [rosbag2_storage]: Opened database 'my_bag/my_bag_0.db3' for READ_WRITE.
[INFO] [1589572027.403285893] [rosbag2_transport]: Listening for topics...
[INFO] [1589572027.403838086] [rosbag2_transport]: Subscribed to topic '/rosout'
[INFO] [1589572027.404197976] [rosbag2_transport]: Subscribed to topic '/parameter_events'

Then when a message is sent:

terminate called after throwing an instance of 'std::logic_error'
  what():  Not implemented
Aborted (core dumped)

Note that I tried both publishing to a topic, using ros2 topic pub like below, and starting a larger project, i.e., turtlebot, which publishes its state. Both produced the same error.

To Reproduce

1. Start recording with the following command:

   ros2 bag record --output my_bag --compression-format zstd --compression-mode message -a
   

2. Send any message, for example with ros2 topic pub /foo std_msgs/msg/String data:\ \'Hi\'\. This should produce the above error.

System

• OS: Ubuntu Focal
• ROS 2 Distro: Foxy
• Version: 0.2.7-1focal.20200514.041002

[emersonknapp]

Thanks for reporting this - I think our fix for Foxy will be to not allow the message option at the CLI level so that it is clearer that message-level compression is not yet available. Taking this onto my plate for the week.

[emersonknapp]

@prajakta-gokhale the fix for this was merged in #415 via not exposing the unimplemented functionality - adding the actual feature is tracked in #414 - what was the reason this was sent back to "in progress"?

[prajakta-gokhale]

I moved it to Done (from Closed) so we would go over it during Sprint Review and close it with consensus. I think some automation moved it to In Progress when I changed sprint milestones.

[audrow]

Hi all, what should we do with this issue? Should we close it, as it is being worked on in #414 as Emerson pointed out?

[emersonknapp]

Yes, we will close this as it now reports correctly.

[emersonknapp]

This was resolved with #415 but we had blocked actually closing the issue (in favor of keeping in the "Done" column on ZenHub) due to an outdated process. Sorry for the confusion.