Under what circumstances will actionlib not mark a MoveBaseGoal as successful?

edit

I'm using a SimpleActionClient) to issue MoveBaseGoals to an instance of /move_base in a flat outdoor environment. If I have the "xy_tolerance" parameter for base_local_planner set to ~0.35m or larger then everything works well without any problems. However, If I reduce the tolerance to 0.25m in an effort to improve navigational accuracy, actionlib stops recognising that it has successfully reached the goal - even if it is repeatably within this tolerance in both the X,Y and Z axis (not that there is a vertical tolerance from what I understand). See below for an example bag file

In this case, the state of the goal remains stuck on '1' (labelled as ACTIVE) and will remain that way indefinitely until I manually cancel it.

So my question is: since all I have changed to cause this behaviour is "xy_tolerance", are there any hidden conditions that must be fulfilled for actionlib to move the state from 1 (ACTIVE) to 3 (SUCCEEDED) other than getting the robot within this distance of the goal point? Or am I likely just hitting the limit on how accurate ROS can be in an outdoor environment? The GPS I'm using is accurate to 20mm, as is the global fused data (verified experimentally).

I'm aware that there are a few other questions that address this issue. However, for the most part they seem to experience this problem regardless, whereas I only see it if I lower "xy_tolerance". So I believe the causes may be different.

Any help or advice is appreciated.

UPDATE 1: I must have been using a slightly older version of move_base and actionlib because I recently updated all my ROS packages and now the goal detection is significantly worse, to the point where it almost never correctly detects if it's reached the goal point, even if it's well within tolerance.

UPDATE 2: As suggested by @David Lu I increased the yaw to Pi (3.14) and conducted a test run. While the larger yaw tolerance significantly increased the rate of goals being successfully recognised, there were still several instances where the robot was within both the X,Y and yaw tolerances and yet it still didn't correctly recognise reaching the goal. I'll upload the bag file shortly.

I've looked through the source code for the internal goal check (goal_functions.cpp) and I noticed that the function checks the last pose in the global path (which is just an array of poses) against the current global position, whereas I'm using the original goal sent to the robot vs the current global position. So is it possible that the global path could have been re-calculated and ended up with a goal pose in a different place to the original?

UPDATE 3: As per @David Lu's suggestion (thanks for the help again!) I checked the end of the global path and the current goal:

• /move_base/current_goal
• /move_base/TrajectoryPlannerROS/global_plan

Both almost perfectly match the goal I originally ... (more)