You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Aug 8, 2023. It is now read-only.
In #8163, we discovered that a series of events that includes removing annotations just as one of the removed annotations is selected can trigger assertions in MGLMapView. This is because queries of mbgl to get annotations in a rectangle return annotation tags that have already been removed from local collections that MGLMapView keeps for tracking purposes.
In #8513, #8588, and #8637 we added protections and removed code that indexed into std::map. These changes stabilized the SDK in release builds. However, debug builds may still trigger assertions because of annotation state race conditions like the one described above.
We should audit MGLMapView to understand all possible cases where state sync issues like this can occur. To truly fix the issue however, we would need some way to sync up with mbgl when annotation state has finished changing.
For example, if Map::removeAnnotation() had a way to call back when an annotation is actually removed, the platform code could hold off on changing its related state until the callback completed. If that were true, we would not expect our assertions about unknown or invalid annotations to be triggered in debug builds.
In #8163, we discovered that a series of events that includes removing annotations just as one of the removed annotations is selected can trigger assertions in
MGLMapView
. This is because queries of mbgl to get annotations in a rectangle return annotation tags that have already been removed from local collections that MGLMapView keeps for tracking purposes.In #8513, #8588, and #8637 we added protections and removed code that indexed into
std::map
. These changes stabilized the SDK in release builds. However, debug builds may still trigger assertions because of annotation state race conditions like the one described above.We should audit
MGLMapView
to understand all possible cases where state sync issues like this can occur. To truly fix the issue however, we would need some way to sync up with mbgl when annotation state has finished changing.For example, if
Map::removeAnnotation()
had a way to call back when an annotation is actually removed, the platform code could hold off on changing its related state until the callback completed. If that were true, we would not expect our assertions about unknown or invalid annotations to be triggered in debug builds.cc @1ec5 @fabian-guerra
The text was updated successfully, but these errors were encountered: