Before proceeding, is there an existing issue or discussion for this?

• I have done a search for similar issues and discussions.

OS and version

Ubuntu 24.04

Open-RMF installation type

Source build

Other Open-RMF installation methods

https://github.com/open-rmf/rmf

Open-RMF version or commit hash

main-12b5980859562a11cb4358c0dc0e34fb9fcec7a6

ROS distribution

Jazzy

ROS installation type

Source build

Other ROS installation methods

No response

Package or library, if applicable

rmf_fleet_adapter

Description of the bug

We have confirmed the occurrence of a deadlock due to an unexpected Mutex lock waiting state.
Mutex is set as shown in the following attached image for the map in the nearby area where the problem occurred.
Please check rmf_demos/rmf_demos_maps/maps/test/test.building.yaml in the attached demo package for details of the map.

Rviz images of the problem are shown below.

Each robot is submitting a task that should be moving downward.
At this time, strangely enough, tinyRobot/tinyRobot5 is trying to lock tinyRobot5_charger_mutex again, even though it has already left.
At this time, a deadlock occurs because tinyRobot/tinyRobot4 has already acquired tinyRobot5_charger_mutex.

[fleet_adapter-17] [INFO] [1750310896.033224395] [tinyRobot_fleet_adapter]: [tinyRobot/tinyRobot5] is waiting to lock mutex group [tinyRobot5_charger_mutex] but that mutex is currently held by [tinyRobot/tinyRobot4]

It is also strange that the yellow marker is shifted from the robot's position.
I would like to ask your advice on whether I should modify the code or the NavigationGraph.
I am also attaching the Rosbag as it appeared when the problem occurred.

rosbag2_2025_06_19-14_24_42.zip

Steps to reproduce the bug

1.rmf_repos.zip is used to build the RMF environment.
2.rmf_demos_gz.zip
rmf_demos_maps.zip
rmf_demos.zip
replace the demonstrations packages.
3.RMF launch

ros2 launch rmf_demos_gz test.launch.xml

4.Task submission

ros2 launch rmf_demos test_loop.launch.xml

Expected behavior

Each robot runs without deadlock caused by Mutex.

Actual behavior

Deadlock is caused by Mutex.

Additional information or screenshots

No response