Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Maps] Fix tileload error messaging / Fix heatmap error message #30327

Merged
merged 7 commits into from
Feb 7, 2019

Conversation

thomasneirynck
Copy link
Contributor

@thomasneirynck thomasneirynck commented Feb 6, 2019

Fixes false error messages that are most apparent in Cloud deployments.

Closes #29886
Closes #29863
Closes #29866

This also closes #30343, by introducing a default implementation of Layer#getOrdinalFields

@elasticmachine
Copy link
Contributor

Pinging @elastic/kibana-gis

@thomasneirynck thomasneirynck added the WIP Work in progress label Feb 6, 2019
copy persistent state using new naming scheme

rename error state

rename previous style

remove cruft

remove unnecessary asyncyness
@thomasneirynck thomasneirynck changed the title Fix tileload error messaging [Ma[s] Fix tileload error messaging Feb 6, 2019
@thomasneirynck thomasneirynck changed the title [Ma[s] Fix tileload error messaging [Maps] Fix tileload error messaging Feb 6, 2019
@elasticmachine
Copy link
Contributor

💔 Build Failed

@thomasneirynck
Copy link
Contributor Author

jenkins, test this

1 similar comment
@thomasneirynck
Copy link
Contributor Author

jenkins, test this

@elasticmachine
Copy link
Contributor

💔 Build Failed

@thomasneirynck
Copy link
Contributor Author

jenkins, test this

@elasticmachine
Copy link
Contributor

💔 Build Failed

@nreese
Copy link
Contributor

nreese commented Feb 7, 2019

Would you mind adding the fix for #30343

in layer.js add a default implementation for getOrdinalFields

async getOrdinalFields() {
  return [];
}

return;
}
if (!source) {
const sourceDataRquest = this.getSourceDataRequest();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

typo: sourceDataRquest -> sourceDataRequest

source: sourceId,
minzoom: this._descriptor.minZoom,
maxzoom: this._descriptor.maxZoom,
});
return;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice. Good call returning before a needless call to set layer props

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

oops, that's actually a bug...

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lol. I was actually just staring at it coming to the same conclusion. we would be doing an extra call to set zoom but alpha isn't covered. there might be a better way to dice those up but a redundant zoom set isn't the end of the world

@kindsun
Copy link
Contributor

kindsun commented Feb 7, 2019

In this revised workflow, if I add a URL I know won't work, the layer is still added to the TOC with no indication it's any different from valid layers. Maybe we should consider dispatching a layer remove action after a timeout callback checks the map and finds the id not present. This would keep the layer list in sync with the map and give the user a more accurate experience in the absence of error messaging.

screenshot from 2019-02-07 10-14-22

@kindsun
Copy link
Contributor

kindsun commented Feb 7, 2019

I think the new pattern you're using for non-persisting properties will be the key to solving #28576 too. Nice! (sorry, linked wrong issue before! hopefully less confusing now)

@thomasneirynck thomasneirynck removed the WIP Work in progress label Feb 7, 2019
@thomasneirynck
Copy link
Contributor Author

thomasneirynck commented Feb 7, 2019

@aaronjcaldwell

Maybe we should consider dispatching a layer remove action after a timeout callback checks the map and finds the id not present.

The issues in Cloud are not about whether we should show an error or not, or whether a faulty layer should stay in the TOC or not. It is about not being able to reliably detect, given the limitations of the mapboxgl-api, whether a given tile-service is functional or not. There's a lot of edge-cases - sparsity in tile coverage, excessive (but expected) latency, .... - that need to be handled, beyond the scope of the bugs described in this PR.

As for detecting if the id is present in the mapbox-map. It is present because the Maps-app is explicitly adding the layer to the mapbox-map during syncing. Mapbox-gl is not removing the layer because it cannot load tiles. That would break the contract of their API.

We could take this question more generically: should faulty or dysfunctional layers stay in the TOC? This question already is sort of answered when introducing the layer-error state in #28852. There are certain very well defined conditions (e.g. cannot find index-pattern id, administrator turned off connection to EMS in the kibana.yml, ....) that the app can detect. The app can present a useful error message for those. Apart from displaying useful hints, if the app would not show the layer in the TOC, a user would not be able to manipulate their map configuration to try and fix the error. That would be a dark pattern imho to remove layers just because there are configuration mismatches, or missing backend dependencies.

@thomasneirynck thomasneirynck changed the title [Maps] Fix tileload error messaging [Maps] Fix tileload error messaging / Fix heatmap error message Feb 7, 2019
Copy link
Contributor

@nreese nreese left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm
code review, tested changes in chrome

if (this._descriptor.dataRequests) {
this._dataRequests = this._descriptor.dataRequests.map(dataRequest => new DataRequest(dataRequest));
if (this._descriptor.__dataRequests) {
this._dataRequests = this._descriptor.__dataRequests.map(dataRequest => new DataRequest(dataRequest));
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This seems error prone to have this._dataRequests with a single underscore and this._descriptor.__dataRequests with a double underscore. Any ideas on how to avoid?

Copy link
Contributor Author

@thomasneirynck thomasneirynck Feb 7, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah .... it looks funny.

We could just revert to single underscore, and ditch the double underscore.

On the other hand, it's a pretty common convention to prepend _ to variables of private state or internal state. But I feel like store-state is something different altogether (just gut feeling..)

Maybe we could just leave as-is for now (?)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yep, leaving as is for now sounds ok.

@elasticmachine
Copy link
Contributor

💔 Build Failed

@thomasneirynck
Copy link
Contributor Author

CI is down.

jenkins, test this

@elasticmachine
Copy link
Contributor

💚 Build Succeeded

@thomasneirynck
Copy link
Contributor Author

@elasticmachine
Copy link
Contributor

💔 Build Failed

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
4 participants