[google_maps_flutter_android] Reindex clustered markers in spatial index on position change

[EverCamilo]

Description

When a clustered marker's position is updated in-place via \MarkersController.changeMarkers(), the \ClusterManager's \NonHierarchicalDistanceBasedAlgorithm\ retains stale \QuadTree\ entries at the old coordinates. This causes ghost clusters to appear at positions where no marker currently exists.

Root cause

\MarkersController.changeMarkers()\ has two code paths when updating a marker:

1. Cluster ID changed — correctly calls
   emoveItem\ + \�ddItem\ on the \ClusterManager, refreshing the spatial index.
2. Same cluster ID (in-place update) — calls \interpretMarkerOptions()\ to update the \MarkerBuilder\ properties (including position), but does not reindex the item in the \ClusterManager. The \QuadTree\ inside \NonHierarchicalDistanceBasedAlgorithm\ stores a \QuadItem\ wrapper that captures the position at insertion time. Without reindexing, the spatial index retains the stale position.

Fix

• Capture the marker's \LatLng\ position before \interpretMarkerOptions()\ updates the builder.
• After the update, compare old vs new position.
• If changed and the marker belongs to a \ClusterManager, call
  emoveItem\ + \�ddItem\ to refresh the \QuadTree.
• Batch variant (
  eindexItems) added for the public \changeMarkers()\ path — calls \cluster()\ only once per \ClusterManager\ for efficiency.

Files changed

• \ClusterManagersController.java: Added
  eindexItem()\ and
  eindexItems()\ methods.
• \MarkersController.java: Added position-change detection and reindex call in both \changeMarkers()\ (batch) and \changeMarker()\ (single) paths.

Reproduction

1. Create a \GoogleMap\ with a \ClusterManager\ and several markers.
2. Programmatically update the position of a clustered marker (keeping the same \MarkerId\ and \ClusterManagerId).
3. Observe that ghost clusters appear at the old positions and persist until the \ClusterManager\ is fully rebuilt.

Pre-launch Checklist

• I read the Contributor Guide and followed the process outlined there for submitting PRs.
• I read the Tree Hygiene wiki page, which explains my responsibilities.
• I read and followed the relevant plugin-specific Contributing guide.
• I listed at least one issue that this PR fixes in the description above.
• I added new tests to check the change I am making.
• All existing and new tests are passing.

[flutter-dashboard]

It looks like this pull request may not have tests. Please make sure to add tests or get an explicit test exemption before merging.

If you are not sure if you need tests, consider this rule of thumb: the purpose of a test is to make sure someone doesn't accidentally revert the fix. Ask yourself, is there anything in your PR that you feel it is important we not accidentally revert back to how it was before your fix?

Reviewers: Read the Tree Hygiene page and make sure this patch meets those guidelines before LGTMing. If you believe this PR qualifies for a test exemption, contact "@test-exemption-reviewer" in the #hackers channel in Discord (don't just cc them here, they won't see it!). The test exemption team is a small volunteer group, so all reviewers should feel empowered to ask for tests, without delegating that responsibility entirely to the test exemption group.

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[gemini-code-assist]

Code Review

This pull request introduces reindexing logic to handle in-place position updates for clustered markers by adding reindexItem and reindexItems methods to ClusterManagersController. However, the review feedback indicates a logic error where marker positions are updated before the removal from the spatial index is triggered. This prevents the ClusterManager from correctly locating and removing markers from their old coordinates in the QuadTree, which would result in the failure to clear stale data.

[gemini-code-assist]

The reindexItem method (and reindexItems below) will fail to remove the item from the spatial index if its position has already been updated. The ClusterManager.removeItem method relies on the item's current getPosition() to locate it in the underlying QuadTree. If the position was mutated before calling this method, the removal will look at the new coordinates, while the item is still indexed at the old coordinates, leading to the "ghost clusters" this PR intends to fix.

[gemini-code-assist]

In changeMarkers, interpretMarkerOptions is called at line 140, which updates the markerBuilder's position. The subsequent call to reindexItems (line 168) will attempt to remove the markers using their new positions. This will fail to clear the old entries from the ClusterManager's spatial index. To fix this, markers whose positions are changing should be removed from the ClusterManager before their state is mutated, or the reindexing logic must be provided with the old coordinates to perform the removal.

[gemini-code-assist]

Similar to the batch update path, in changeMarker, the markerBuilder is updated at line 397 before reindexItem is called. This prevents the ClusterManager from correctly identifying and removing the marker from its old position in the spatial index because removeItem will be searching at the new coordinates.