FollowJointTrajectory Action does not generate Register code

Using version 0.6.0 of the ROS TCP Connector I am working on a action interface for a Joint Trajectory Controller.
For this I generated the code for FollowJointTrajectory.action using the standard 'Generate ROS Messages...' and the message code for the action found here https://github.com/ros-controls/control_msgs.

However, when I try to register a publisher for the ActionFeedback:

feedbackTopic = ros.RegisterPublisher<FollowJointTrajectoryActionFeedback>(feedbackTopicName);

I experience a lot of errors at the ROS side: Failed to resolve message name: list index out of range
And on the Unity side: SysCommand.publish - Unknown message class ''

Further investigation shows that the the FollowJointTrajectoryActionFeedback is not registered in the MessageRegistry. As a result of that, the name of the message is not set, causing the error messages above.

Other other generated messages like FollowJointTrajectoryFeedback (without Action in the name) have explicit code for Registering. When I add this code to the generated FollowJointTrajectoryActionFeedback code, the errors are resolved:

Code (CSharp):

1. #if UNITY_EDITOR
2.         [UnityEditor.InitializeOnLoadMethod]
3. #else
4.         [UnityEngine.RuntimeInitializeOnLoadMethod]
5. #endif
6.         public static void Register() {
7.             MessageRegistry.Register(k_RosMessageName, Deserialize, MessageSubtopic.Feedback);
8.         }

Is this a bug or am I not supposed to register an ActionFeedback topic?
I took inspiration for this implementation from the Pick-and-Place tutorial part 4: https://github.com/Unity-Technologies/Unity-Robotics-Hub/blob/main/tutorials/pick_and_place/4_pick_and_place.md.

Thanks,
Pascal Serrarens.

 

Thank you for confirming this.
In the meantime I found that there are indeed more issues with the ActionLib support (the deserialization of a Action Goal message failes with a NullPointer exception).
On the other hand, in our project we found that we do not need the Action Interface on a short term, so we decide to postpone this part for now.
(On the other hand: we will probably need support for the Parameter Server for which we also may need to implement a custom solution for the time being...)