DeserializationError cannot deserialize: unknown error handler name 'rosmsg'

[rovbo-maksim]

The latest ROS Melodic update upgraded the genpy package from 0.6.14 to 0.6.15. It causes an error (DeserializationError cannot deserialize: unknown error handler name 'rosmsg') to occur in a system that worked well before the upgrade. I was not able to detect the exact cause of the error, but it seems to be very similar to the previously known bug discussed in:
PR #127
https://answers.ros.org/question/360537/unknown-error-handler-name-rosmsg/?answer=360643#post-id-360643

Downloading and building the genpy package (version tag 0.6.14) from source fixes the problem (0.6.15 built from source causes the problem, too).

[YiHerngOng]

Agreed, I have the same issue as well. Just did a revert back to previous version and it worked.
Thanks for the help. I am surprised that this kind of official update would cause an issue.

[jaejyn]

The latest ROS Melodic update upgraded the genpy package from 0.6.14 to 0.6.15. It causes an error (DeserializationError cannot deserialize: unknown error handler name 'rosmsg') to occur in a system that worked well before the upgrade. I was not able to detect the exact cause of the error, but it seems to be very similar to the previously known bug discussed in:
PR #127
https://answers.ros.org/question/360537/unknown-error-handler-name-rosmsg/?answer=360643#post-id-360643

Downloading and building the genpy package (version tag 0.6.14) from source fixes the problem (0.6.15 built from source causes the problem, too).

@SilentPony Could you kindly let me know how to downgrade the package? I have same problem but I don't know how to downgrade it. (I am using Ubuntu 18.04 + melodic ros)

I tried to search available packages to downgrade it but there wasn't another package but 0.6.15

[rovbo-maksim]

The latest ROS Melodic update upgraded the genpy package from 0.6.14 to 0.6.15. It causes an error (DeserializationError cannot deserialize: unknown error handler name 'rosmsg') to occur in a system that worked well before the upgrade. I was not able to detect the exact cause of the error, but it seems to be very similar to the previously known bug discussed in:
PR #127
https://answers.ros.org/question/360537/unknown-error-handler-name-rosmsg/?answer=360643#post-id-360643
Downloading and building the genpy package (version tag 0.6.14) from source fixes the problem (0.6.15 built from source causes the problem, too).

@SilentPony Could you kindly let me know how to downgrade the package? I have same problem but I don't know how to downgrade it. (I am using Ubuntu 18.04 + melodic ros)

I tried to search available packages to downgrade it but there wasn't another package but 0.6.15

There are no archived versions of the binary packages in the ROS repositories as far as I am aware, so you need to create a catkin overlay and download the genpy source there, build the overlay workspace, source it, then delete build and devel directories in your catkin workspace and rebuild it so that it uses the overlay workspace as an extension. At least, that's what I did.

Or I guess you could just download the correct branch of genpy directly into you catkin workspace source and rebuild it.

[apojomovsky]

I can confirm we're experimenting the same error.

The workspace overlay to genpy 0.6.14 did the trick, though. Thanks for pointing it out @SilentPony .

[gavanderhoorn]

According to the changelog, only #131 and #134 were merged between 0.6.14 and 0.6.15: 0.6.14...0.6.15

It would be great if those of you experiencing this could do a manual bisect (seeing as it's only two sets of changes) and see which one introduces the regression.

---

Edit: I'm guessing it's going to be #134.

[gavanderhoorn]

@sloretz: the 0.6.15 release appears to introduce a regression. Should it be reverted or fixed before the next sync?

[apojomovsky]

@gavanderhoorn you're right. I just checked what you suggested bisecting the two changes and this error points to #134.

[gavanderhoorn]

Ok, thanks for doing that.

I've not actually checked what #134 does/adds, so I wouldn't know how to fix it right now.

[sloretz]

Looking into it. @SilentPony @apojomovsky what are the steps I need to do locally to see the DeserializationError?

[gavanderhoorn]

Looking into it. @SilentPony @apojomovsky what are the steps I need to do locally to see the DeserializationError?

From the error message (and the context of the previous PR) I'd assume receiving messages (potentially with Unicode in them?) should trigger it.

@apojomovsky @SilentPony: correct?

[rovbo-maksim]

Looking into it. @SilentPony @apojomovsky what are the steps I need to do locally to see the DeserializationError?

From the error message (and the context of the previous PR) I'd assume receiving messages (potentially with Unicode in them?) should trigger it.

@apojomovsky @SilentPony: correct?

That was my assumption, but it seems that the problem is different. I found that completely rebuilding the same code in a new workspace eliminates the error. So it must be caused by some incompatibility between something in the workspace that was built with the earlier version of the library and the new one? I also did not find any non-ASCII symbols in the messages, though perhaps the encoding was somehow different.

In my case, the error seems to occur right before a service callback of a service with a custom message, but since the rebuilding from scratch helps, the problem must be mostly unrelated to the service in question (and the service call did not have any unicode in it). I will try to find a way to reproduce the error or otherwise narrow it down, but it seems much less important since it can be remedied by simply cleaning and rebuilding and at the same time much harder to debug.

Maybe others who have this problem should try cleaning the workspace and rebuilding to confirm that it solves the problem and it is caused by some artifact from the previous builds?

[eggerk]

We have noticed the same issue and it seems that the genpy update breaks the interaction with messages that were built with genpy 0.6.14.

The following worked for me to reproduce this issue on Ubuntu Bionic/ROS Melodic:

1. Compile custom ROS messages and packages with genpy 0.6.14 installed.
2. Confirm that rostopic echo <custom_message> or rosservice call <custom service> works.
3. Update genpy to 0.6.15.
4. rostopic echo no doesn't give a result, despite the publisher (C++) still producing (I haven't restarted it in between). Similarly, a rosservice call will go correctly to the service server (C++ in my case), but the response cannot be parsed:

   ERROR: transport error completing service call: receive_once[/state_machine/command]: DeserializationError cannot deserialize: unknown error handler name 'rosmsg'
   

5. Cleaning the workspace and rebuilding everything with genpy 0.6.15 resolves the issue, as does downgrading genpy to 0.6.14.

[sloretz]

We have noticed the same issue and it seems that the genpy update breaks the interaction with messages that were built with genpy 0.6.14.

Oh okay. I think I understand what's going on and why #134 is at fault. Rebuilding messages seems like the best workaround if you have the option. Python 3 users, like all users of ROS Noetic or Arch users of ROS Melodic, are unaffected and don't need to worry about it.

#134 PR changed the generated code for messages to only set an attribute on the rosmsg codec if the code is using Python 3 instead of setting the attribute all the time. It also changed the genpy python module to only register the codec when using Python 3. If your messages were built with genpy 0.6.14 and you're using Python 2 and genpy 0.6.15 at runtime, then the generated message will try to look up a codec that the runtime version of genpy hasn't registered.

For those that can't rebuild their messages, how about we make genpy always install the rosmsg codec even if it's unused? Then messages generated with 0.6.14 will be able to lookup the codec to set the msg_type attribute (a noop because it' won't be used) without crashing in Python 2.

Thank you @eggerk and @silentpony for the steps and extra info.

[ros-discourse]

This issue has been mentioned on ROS Discourse. There might be relevant details there:

https://discourse.ros.org/t/do-not-upgrade-your-local-melodic-installs-for-now-regression/20163/1

[peci1]

Does anyone have the binary .deb of 0.6.14?

[eggerk]

@peci1 The package for Debian stretch is still available as a deb here. It worked on Ubuntu Bionic as well for us as it's only Python files.

[peci1]

Thanks. Here it is just in case somebody needs it quickly and the buildfarm file gets overridden:
ros-melodic-genpy_0.6.14-1stretch.20201017.031749_amd64.zip

[flixr]

@sloretz a new release of genpy which always registers the codec would be really appreciated. So basically going with #133 instead of #134

[sloretz]

Fix included in 0.6.16 release ros/rosdistro#29378

[ros-discourse]

This issue has been mentioned on ROS Discourse. There might be relevant details there:

https://discourse.ros.org/t/preparing-for-final-kinetic-sync/19805/6

[ros-discourse]

This issue has been mentioned on ROS Discourse. There might be relevant details there:

https://discourse.ros.org/t/preparing-for-melodic-sync-2021-04-23/20036/3

[shu-agrointelli]

Any ETA of when the fix is deployed to the PPA?

[peci1]

Soon: https://discourse.ros.org/t/preparing-for-melodic-sync-2021-05-10/20326