Now that "versioned maps" is deployed, we can see that some mapdata failures shouldn't be happening and must be due to bugs. When the revid parameter is present, we expect that parsed article content is stable aside from changes to content transcluded into the mapframe, and known bug T246314 where parsing is split and gives different results by interface language.
Taking one example of a map failing although revid is present, https://en.wikipedia.org/wiki/The_Ramble_and_Lake at revision 1081204090 yields groupId _d0cdae7fc26ee2076758eaf605a31364bb0b6cfc, returning a mapframe transcluded entirely from {{Central Park map}}. Neither the page, the template, or any of the transcluded sub-templates and modules have been modified since at least April. Filtering logs to request.query.title=The Ramble and Lake, we can see that the page has been consistently getting errors requesting the same wrong group IDs, since before the versioned maps deployment on May 11. The incorrect hashes that have been requested are _e217d6457677e415dcf9851a96d76d066f939dbb and _252b536d06ba5418bd0b2cf682523dacdc074b3f, and these have been consistently requested for over a month. Since requests with the revid parameter must have been rendered after the versioned maps deployment, we can know that the page contents are recently generated and not coming from a stale cache.
Perhaps something about the users' request is causing the parsed page to vary, as in the LanguageConverter case. This is a different bug, however—applying "uselang" to the mapdata API seems to do nothing, as expected.
We should determine whether these are logged-in or anonymous users, but judging by the user-agents, this seems to include anons. The only options which should be able to split cache are listed in ParserOptions: https://github.com/wikimedia/mediawiki/blob/master/includes/parser/ParserOptions.php#L81
- dateformat
- thumbsize
- printable
- userlang
An extension could add its own varying options as well.
We should try to find a way to vary options while requesting this page, to learn what conditions are causing the two incorrect groupIds. But generally, it seems that parser cache variations need to be handled by mapdata, or somehow ignored while parsing if that can be done safely.