Fix infinite spinner when 400 error occurs due to 50k node limit by s…

[Shyam-123pandey]

Fix infinite spinner when OSM API returns 400 for large bbox #11459

What this fixes

When the OSM API returns a 400 Bad Request for /map.json?bbox=... (typically caused by the 50k node limit), the editor keeps retrying the same tile and the loading spinner never stops.

Even after API requests stop in the network tab, the tile remains in _tileCache.inflight, so the spinner continues indefinitely.

What was changed

• Added safe handling for 400 responses
• Subdivide tiles when possible (up to a max depth)
• Properly clear _tileCache.inflight and _tileCache.toLoad
• Ensure the spinner stops once all inflight requests are resolved

Result

Please take a look of vedio: https://drive.google.com/file/d/1-3UsnZWG6jUg05__sEQULTYYidnYVkZg/view?usp=drive_link

• No infinite spinner
• No repeated 400 requests
• Editor returns to a stable state

Tested by forcing a bbox that exceeds the 50k node limit.
I have added a vedio in comment of this issue if want please you can check for fixes.
Thanks

[Copilot]

Pull request overview

This pull request attempts to fix an infinite spinner issue that occurs when the OpenStreetMap API returns a 400 Bad Request error due to exceeding the 50,000 node limit for a bounding box query. The fix introduces tile subdivision to break large tiles into smaller quadrants when a 400 error is encountered, and adds state management with a new _isLoading flag to track loading status.

Changes:

• Added 400 error handling with automatic tile subdivision up to 3 levels deep
• Introduced _isLoading flag to track loading state independently of inflight requests
• Modified retry logic to handle 400 errors differently from rate limit errors

[Shyam-123pandey]

Improve 400 tile subdivision logic

This update refactors the 400 (50k node limit) subdivision logic to use the existing geoExtent.split() method instead of manually computing quadrant bounding boxes.
I want make sure one thing that :
Using split() keeps the implementation consistent with other parts of the codebase (e.g. streetside) and avoids duplicating logic??

To maintain compatibility with existing test fixtures that use mocked extent objects without a split() method, a guarded fallback should be included. If split() is not available, the quadrants should be computed manually and converted to geoExtent instances.
This ensures:

• Proper reuse of existing geometry utilities
• No regression in existing tests
• No change in runtime behavior
  Then all test cases will be pass.

[Shyam-123pandey]

Improve 400 tile subdivision logic

This update refactors the 400 (50k node limit) subdivision logic to use the existing geoExtent.split() method instead of manually computing quadrant bounding boxes. I want make sure one thing that : Using split() keeps the implementation consistent with other parts of the codebase (e.g. streetside) and avoids duplicating logic??

To maintain compatibility with existing test fixtures that use mocked extent objects without a split() method, a guarded fallback should be included. If split() is not available, the quadrants should be computed manually and converted to geoExtent instances. This ensures:

• Proper reuse of existing geometry utilities
• No regression in existing tests
• No change in runtime behavior
  Then all test cases will be pass.

i did this and resolved all issues, please take a review of this. Thanks.

[Shyam-123pandey]

Hello Sir , Please tell when this will be merged to main codebase?