Provide more information about errors in mapbox
Motivation
Right now, If there is an error, Mapbox will throw an error with an error message. There is no way to programmatically check the type of error and if the error is related to a layer, a style expression , ...etc. It will be nice to have error type and metadata associated with the error so that the host application will be able to handle error better.
Background: Given an application that allows the user to load layers from different sources, if a layer filter fails, The application should be able to know the type error and the action that caused so that it can remove the problematic error.
Design Alternatives
Design
Mock-Up
Concepts
Implementation
Have you tried using the on('error') event? I haven't, but in theory you could parse the description to find out which layer caused it.
I tried the on('error') event but it only displays an error message. Parsing description to find out error is not sustainable as the message could change and sometimes the message does not contain enough detailed information. It would be nice to know for each error event the origin of the error, the type of error or an error code. For instance, was the error caused inside a layer or a style? can I get the layer id and so that I can take action?
Given an application that allows the user to load layers from different sources, if a layer filter fails, The application should be able to know the type error and the action that caused so that it can remove the problematic error.
@kikonejacob it sounds like you have an application that allows customers to bring their own source data and provide their own expressions/filters. One approach would be to validate these before passing them to mapbox-GL-JS. This can be done by using the style-spec module and it's validate*** methods.
If you are only interested in validation or error reporting on expressions, we could close this ticket and move the discussion over to https://github.com/mapbox/mapbox-gl-js/issues/6345
Given an application that allows the user to load layers from different sources, if a layer filter fails, The application should be able to know the type error and the action that caused so that it can remove the problematic error.
@kikonejacob it sounds like you have an application that allows customers to bring their own source data and provide their own expressions/filters. One approach would be to validate these before passing them to mapbox-GL-JS. This can be done by using the style-spec module and it's
validate***methods.If you are only interested in validation or error reporting on expressions, we could close this ticket and move the discussion over to #6345
@asheemmamoowala Thanks for your answer.
The use of validation is definitely needed. I like the idea of using style-spec. The @mapbox/mapbox-gl-style-spec package exposes a validate method for style only. Is it possible to expose validate source , filter, expression , paint, layer etc..
Another point to consider is that mapbox error can still happen even if the style is ok but a network issue occurs such as wms server is down etc ... So better error specifications are still needed. The error message only is not enough.
As a background, we have a complex application that allows the user to add sources and layers from a catalog that is maintained by our team. The application allows user to change the filter, symbolization, etc after the layer was added ... Our customers required error-tolerant app and we want to be able to recover from error without breaking the map. If Mapbox error occurs for network, style error, or any other reason the application needs to handle the error gracefully and notify the user and log it for developers. Just not displaying layers in the map is not ok for our user. The application needs to find the issue and resolve it and display a polished message to the user.
I agree with @kikonejacob, I think better errors would be beneficial. I've also attempted to use the @mapbox/mapbox-gl-style-spec but the functions were not exposed that I needed. I would like to use it down to the level of validating circle-color expression or validating a filter without having to pass the entire layer configuration to the validator.
Is it possible to expose validate source , filter, expression , paint, layer etc..
Yes, this is possible. I have provided some guidance on how this could be done in https://github.com/mapbox/mapbox-gl-js/issues/7670#issuecomment-444998870. We'd welcome a PR that exposes this type of granular validation.
I'm in a similar situation, I have an API which my raster tile source points to with a URL supplied to tiles like described in the docs: https://docs.mapbox.com/mapbox-gl-js/api/sources/#rastertilesource.
If I listen to the 'error' callback, I get an ErrorEvent type where the only properties available appears to be "type" (which is "error" in this case) and error which is the native Error interface only allowing "name", "message", and "stack".
This doesn't help for cases where:
- I want to evaluate an Http status associated with the error.
- Tell which URL endpoint failed, if I have more renderers which are calling different endpoints for other visualization purposes then I'd like to be able to differentiate on the client end which renderer caused the .on('error') callback. This isn't possible at the moment as the callback is on the map instance where there can be multiple sources.