@TheDJ Thanks for pushing this discussion forward and sorry for the silence on it, it wasn't intentional but rather related to multiple stuff happening on our end that put maps priority down the list.

It doesn't seem that there's something actionable on Parsoid side. Please re-add the tag in case I'm missing something.

This is still happening in Android and iOS on the other hand is solving this by opening a web view for the unsupported namespaces, I wonder if we could keep it consistent between apps cc/ @JMinor and @JTannerWMF

This seems to be fixed upstream. I'll be bold and close it, please reopen in case I'm missing something.

@Elitre what's the best way to reach out to the Template Editors?

@cooltey considering @Nikerabbit suggestions of using different messages: can you help us advance with that?

@cooltey apparently, this is somewhat related to parsoid output, see: https://en.wikipedia.org/api/rest_v1/page/html/User:CFeng_(WMF)

@MattCleinman these 2 endpoints have specific behaviors that I don't think we can/should be making consistent:

• The feed featured endpoint crawls the pages provided by the FeatureFeed extension
• The onthisday endpoint crawls pages created and maintained by the community such as https://en.m.wikipedia.org/wiki/May_20

In T298814#7986998, @MattCleinman wrote:

No giant rush, but do you know when this will be deployed?

@cooltey do you have any idea if this information comes from the Android App logic or mobile-html output?

@lilients_WMDE do you have any links to reproduce the issue?

A side-note that we should create a follow-up action is: these logs are not registered as errors, but as notices, which make it harder to debug.

@Jdlrobson should be merged as part of https://gerrit.wikimedia.org/r/c/operations/deployment-charts/+/773595

@WDoranWMF and @DAbad it seems that the chromium-render service (proton or PDF renderer) doesn't have a task yet, but it is part of restbase (see code here)

@cooltey the beta cluster doesn't have edge cache AFAIK.

Cross-posting here: I have used the mobileapps diff tests to generate fixtures for the zhwiki test comparing your latest patch with the last commit before action=parse was introduced, here is the result https://phabricator.wikimedia.org/transactions/detail/PHID-XACT-PSTE-lecdnh7lt2ppzsx/

@akosiaris the initial geoshapes deployment-charts is created and ready to move forward: https://gerrit.wikimedia.org/r/c/operations/deployment-charts/+/768678

These are expensive queries though. It's important to note that geoshapes and snapshot are rendered on the fly and then stored in the varnish cache layer.

In T277059#7757516, @vadim-kovalenko wrote:

Tried to retrieve specific Serbian articles using RESTBase API. For example for Voće (this is serbian latin word)
This article exists in the desktop wiki - https://sr.wikipedia.org/sr-el/Vo%C4%87e
But response from the REST API is not found. Check - https://sr.wikipedia.org/api/rest_v1/page/html/Vo%C4%87e.
My assumption is that mobilapps nor RESTBase know nothing about /sr-el directory path which is utilizing in the desktop wiki. By the way, related tests in the mobiileapps (run ./node_modules/mocha/bin/mocha test/lib/wikiLanguage/wikiLanguage-test.js) and in the RESTBase (run ./node_modules/mocha/bin/mocha test/features/pagecontent/language_variants.js) work fine. I hope this research was useful. Can someone assist of how /sr-el or /sr-cr consumed by the RESTBase?

Nice work! The next step is to get rid of maps/kartotherian/package and move the needed functionality to the monorepo, I'll get a starter patch for that.

In T274388#7751113, @akosiaris wrote:

In T274388#7744335, @MSantos wrote:

Set up the traffic layer to send traffic to the service (if needed). This is a bit unclear to me currently. I am not sure from the diagrams whether the user's browser will need to talk to geoshapes (via the edge traffic layers) or kartotherian will talk to geoshapes, or both.

With the extraction, kartotherian and geoshapes shouldn't be related anymore. So we should set up the traffic layer to send geoshape's endpoint traffic to the new service

So maps.wikimedia.org/geoshape specifically should be routed to the new service? Or can we create a new DNS for this, e.g. geoshapes.wikimedia.org? The former isn't so easy as the latter and might not even be desirable on Traffic's side, hence my question.

Set up the traffic layer to send traffic to the service (if needed). This is a bit unclear to me currently. I am not sure from the diagrams whether the user's browser will need to talk to geoshapes (via the edge traffic layers) or kartotherian will talk to geoshapes, or both.

@awight I also think kartodock can be moved altogether, it will be easier when kartotherian is converted into a monolith

@akosiaris and @jijiki how can we move forward with this?

Brain dumping my preliminary investigation.

In T218097#7614102, @TheDJ wrote:

Of note is that what is missing are some pretty sizeable elements. Makes u wonder if size of body (even mtu or transaction time) is causing a problem. Is it a coincidence we lost the lakes twice ? In two different systems ? That’s suspicious.

@TheDJ and @Ferdi2005 sorry for the late response. I've posted an explanation about our finds during the investigations on this issue and how we are working to have a proper fix at T218097: [Bug] OSM DB degradation during sync as a result of missing features. Please let me know if you have any questions or concerns.

@MPhamWMF the PDF handler we maintain might not be related because it's a nodejs service that generates PDF on the fly for the requested wiki page and it doesn't handle uploaded PDF files.

@Tohaomg the fix should be up in a couple of hours but it might take a full day until tiles are refreshed, I'll keep you posted.