[ctw-joao-luis]

User-Facing Changes

There were cases when Teleop panel completely crashed Lichtblick because it would try to publish a message faster than topic would be advertised, with this fix this error should not happen again.

Fixes #554

Description

Problem: The publish effect and advertise effect are asynchronous and independent. When a button is clicked, the code attempts to publish a message immediately, but there's a race condition where the topic may not be fully ready yet, causing an unhandled exception that crashes the entire panel.

(I was only able to reproduce the error on Lichtblick's web version on dev mode)

Added try-catch error handling around all context.publish() calls:

So now the try and catch catches the exception instead of letting it crash the component, then setIntreval() retries publishing the message and eventually, even if the publish fails once or twice more, the publish will work because the topic will be finally ready and no more crashes will happen.

HOW TO TEST:

1. Build and run this image

FROM osrf/ros:humble-desktop

RUN apt-get update && \
    apt-get install -y \
      ros-humble-foxglove-bridge \
      ros-humble-geometry-msgs \
    && rm -rf /var/lib/apt/lists/*

SHELL ["/bin/bash", "-c"]
RUN echo "source /opt/ros/humble/setup.bash" >> /root/.bashrc

EXPOSE 8765

CMD ["bash", "-c", "\
  source /opt/ros/humble/setup.bash && \
  ros2 topic echo /cmd_vel geometry_msgs/msg/Twist & \
  ros2 launch foxglove_bridge foxglove_bridge_launch.xml \
"]

docker build -t lichtblick-teleop-sim .
docker run -it --rm --network host lichtblick-teleop-sim

2. Open Lichtblick with a websocket connection and connect to port 8765

3. Use teleop panel and confirm the messages are being published on the terminal the image is running

Checklist

• The web version was tested and it is running ok
• The desktop version was tested and it is running ok
• This change is covered by unit tests
• Files constants.ts, types.ts and *.style.ts have been checked and relevant code snippets have been relocated

[rodrigo-p-rodrigues]

lgtm!

Note:
Instead of running on host mode, exposing ports worked for me:
docker run --rm -p 8765:8765 lichtblick-teleop-sim

[ctw-joao-luis]

So I identified the problem, trying to publish a message before advertising, still persisted on first render. Basically unadvertised was being called on the initial render so I implemented an useRef to guarantee that the first render doesnt trigger an unadvertise() call automatically

[ctw-joao-luis]

Had to make a change on a unit test to actually transcribe what's happening. I discovered why I was only able to reproduce this bug on dev mode. Because of React Strict Mode, the component would get rendered twice making it that:

1. Component mounts
2. useLayoutEffect runs → advertise() called
3. useLayoutEffect cleanup runs → unadvertise() called
4. useLayoutEffect runs AGAIN → advertise() called again

This was the reason for the bug and why I was not able to reproduce it on Prod.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
100.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[rodrigo-p-rodrigues]

Tested it and the issue is fixed, which is an improvement for the users.
I think some of the existing unit tests should be reviewed at some point.