map.fitBounds with maxZoom=undefined throws Invalid LngLat object: (NaN, NaN)

[theprojectsomething]

mapbox-gl-js version: 1.12.0

browser: All of them

Steps to Trigger Behavior

1. Create a map
2. fit it to some bounds
3. this time, stuff up and pass it an undefined value for maxZoom without realising
4. spend many hours debugging

Link to Demonstration

https://jsfiddle.net/jxoya0cn/

Expected Behavior

Warn that an invalid value has been passed. Disregard / allow for an invalid zoom constraint.

Actual Behavior

💣 Invalid LngLat object: (NaN, NaN)

[jaybo]

Possibly the same bug on V2.0, but different trigger situation. To the best of my knowledge, I didn't set maxZoom to undefined value. One thing to note: this is only happening on a callback completion event for an axios HTTP GET.
Stack:

onViewReset Error: Invalid LngLat object: (NaN, NaN)
    at new bc (webpack-internal:///./node_modules/mapbox-gl/dist/mapbox-gl.js:30:310627)
    at zc.toLngLat (webpack-internal:///./node_modules/mapbox-gl/dist/mapbox-gl.js:30:312227)
    at io.coordinateLocation (webpack-internal:///./node_modules/mapbox-gl/dist/mapbox-gl.js:34:279296)
    at eval (webpack-internal:///./node_modules/mapbox-gl/dist/mapbox-gl.js:34:282144)
    at Array.reduce (<anonymous>)
    at io._getBounds3D (webpack-internal:///./node_modules/mapbox-gl/dist/mapbox-gl.js:34:282116)
    at io.getBounds (webpack-internal:///./node_modules/mapbox-gl/dist/mapbox-gl.js:34:281450)
    at Map.getBounds (webpack-internal:///./node_modules/mapbox-gl/dist/mapbox-gl.js:34:361667)
    at onViewReset (webpack-internal:///./src/modules/tideEngine.js:970:20)
    at eval (webpack-internal:///./src/modules/tideEngine.js:533:9) {stack: 'Error: Invalid LngLat object: (NaN, NaN)

Here's the state of the map object at the moment of the exception:

_antialias:undefined
_bearingSnap:7
_canvas:canvas.mapboxgl-canvas
_canvasContainer:div.mapboxgl-canvas-container.mapboxgl-interactive.mapboxgl-touch-drag-pan.mapboxgl-touch-zoom-rotate
_clickTolerance:3
_collectResourceTiming:undefined
_container:div#map.DZmap.mapboxgl-map
_contextLost:ƒ ()
_contextRestored:ƒ ()
_controlContainer:div.mapboxgl-control-container
_controlPositions:{top-left: div.mapboxgl-ctrl-top-left, top-right: div.mapboxgl-ctrl-top-right, bottom-left: div.mapboxgl-ctrl-bottom-left, bottom-right: div.mapboxgl-ctrl-bottom-right}
_controls:(6) [Qo, ea, MapboxDraw, NavigationControl, GeolocateControl, ScaleControl]
_crossFadingFactor:1
_crossSourceCollisions:true
_fadeDuration:300
_failIfMajorPerformanceCaveat:false
_frame:{cancel: ƒ}
_fullyLoaded:true
_hash:false
_interactive:true
_isInitialLoad:true
_listeners:{data: Array(4), move: Array(6), moveend: Array(6), zoom: Array(4), styledata: Array(1), …}
_loaded:true
_locale:{AttributionControl.ToggleAttribution: 'Toggle attribution', AttributionControl.MapFeedback: 'Map feedback', FullscreenControl.Enter: 'Enter fullscreen', FullscreenControl.Exit: 'Exit fullscreen', GeolocateControl.FindMyLocation: 'Find my location', …}
_localIdeographFontFamily:'sans-serif'
_logoControl:ea {_updateLogo: ƒ, _updateCompact: ƒ, _map: Map, _container: div.mapboxgl-ctrl}
_mapId:1
_maxTileCacheSize:5000
_missingCSSCanary:div.mapboxgl-canary
_moving:false
_oneTimeListeners:{load: Array(0)}
_onMapScroll:ƒ ()
_onWindowOnline:ƒ ()
_onWindowResize:ƒ ()
_padding:false
_pitching:false
_placementDirty:false
_preserveDrawingBuffer:false
_refreshExpiredTiles:true
_renderFrameCallback:ƒ ()
_renderNextFrame:true
_renderTaskQueue:ta {_queue: Array(0), _id: 0, _cleared: false, _currentlyRunning: false}
_requestManager:t.RequestManager {_transformRequestFn: null, _customAccessToken: null, _skuToken: '101SlaR82YPZ8', _skuTokenExpiresAt: 1607785737226}
_rotating:false
_sourcesDirty:true
_styleDirty:false
_trackResize:true
_zooming:false

[jonesmac]

Similar experience. I don't think the issue is on the initial map load. but when an additional maxZoom value is passed AFTER the map has been configured.

As a workaround, you can conditionally pass the property with a valid value and the error is avoided.

[SnailBones]

We don't currently have any type-checking errors and if we decide to implement this it should be part of a larger push to change that, so I'm closing this ticket and we can move conversation to #9485

More context (referring to similar issue #4385) in #12098 (comment):

While this is a useful exception on developer errors, we don't have precedent of type safety errors on other APIs. Type safety is done with static type annotations, and while I imagine that not all external developer adopt the same type checking as part of their tooling, it's not trivial to exhaust every possible type checks at runtime as this is better suited for static analysis. If we introduce this, we would start to be inconsistent with other APIs and probably be asked to adopt similar patterns elsewhere.