Example: https://de.wikivoyage.org/wiki/Kairo/Ta%E1%B8%A5r%C4%ABr-Platz

The same error occurs on English Wikivoyage, too.

Some tests on https://de.wikivoyage.org/wiki/Kairo/Ta%E1%B8%A5r%C4%ABr-Platz

The map markers are not shown because of timeout of the map server and because of a programming failure in Mediawiki's Karthographer Javascript scripts. At the German Wikivoyage the are two scripts presenting maps. The Mediawiki scripts do nothing in case of timeout (see maps in article and full-screen maps). Below the map in the bottom right corner, there is a magnify button. If you press it the markers are shown because the map is presented in case of timeout, too. Three objects are missing: the Cairo metro lines from WMF's map server.

The map server returns a 404 error.

@MSantos this seems like a reordering of the deploy street broke the /geoline endpoints of maps.wikimedia.org ?

https://maps.wikimedia.org/geoline?getgeojson=1&ids=Q5017773

Simply returns: Cannot GET /geoline

@TheDJ actually, geoshapes is not being able to connect to the database, maybe due to the recent OSM resync. My assumption is that the replicas in the eqiad cluster are still updating. cc/ @hnowlan

It is not the first time that the map server is not working properly (T231964, T226412). But these malfunctions should not block drawing map structures which are not fetched from the mapserver/OSM database. The non-database structures are drawn only after a successful fetching of geolines and geoshape objects. If the fetching failed then the drawing of non-database structures will be blocked because of errors of JavaScript promises. This should not happen in any case. That's why I propose the following two changes:

• The geoline (https://maps.wikimedia.org/geoline?getgeojson=) and geoshape (https://maps.wikimedia.org/geoshape?getgeojson=) functions should return at least an empty JSON object to prevent errors of JavaScript promises.
• The JavaScript functions which try to fetch OSM objects shall draw non-OSM objects in case of mapserver failures in a manner as shown in the following example:

Promise.all( promiseArray )
	.then( function() { drawAll(); } )
	.catch( function() { drawAllNonOsmObjects(); } );

I think the promises are handled in Kartographer\lib\wikimedia-mapdata.js.

The maps clusters in both datacentres are now stable and these URLs appear to be working now. More accurate errors should probably be returned for these endpoints misbehaving.

In T267296#6608020, @RolandUnger wrote:

It is not the first time that the map server is not working properly (T231964, T226412). But these malfunctions should not block drawing map structures which are not fetched from the mapserver/OSM database. The non-database structures are drawn only after a successful fetching of geolines and geoshape objects. If the fetching failed then the drawing of non-database structures will be blocked because of errors of JavaScript promises. This should not happen in any case. That's why I propose the following two changes:

• The geoline (https://maps.wikimedia.org/geoline?getgeojson=) and geoshape (https://maps.wikimedia.org/geoshape?getgeojson=) functions should return at least an empty JSON object to prevent errors of JavaScript promises.
• The JavaScript functions which try to fetch OSM objects shall draw non-OSM objects in case of mapserver failures in a manner as shown in the following example:

Promise.all( promiseArray )
	.then( function() { drawAll(); } )
	.catch( function() { drawAllNonOsmObjects(); } );

I think the promises are handled in Kartographer\lib\wikimedia-mapdata.js.

@RolandUnger the problem is solved, but your proposed changes to make geoshapes more robust seems reasonable, could you update the task description to reflect that? Or create a new task for that so we can close this one?

This proposed change seems reasonable, but if I’m not mistaken, that codepath is shared between the static map generation and the Front-end... if we generate ‘half’ rendered static maps, then how long would these be cached (without a method to purge them) @MSantos ?

This is not related to Traffic. If I'm missing something obvious, please re-add it.

In T267296#6649896, @TheDJ wrote:

This proposed change seems reasonable, but if I’m not mistaken, that codepath is shared between the static map generation and the Front-end... if we generate ‘half’ rendered static maps, then how long would these be cached (without a method to purge them) @MSantos ?

@TheDJ we could change cache max-age when we are serving incomplete data. If that's not enough we should start thinking about how to improve cache purging, what do you think?