Thanks @cmadeo and @JoeWalsh for taking a look at this, I will move this to the backlog for now.

On another note, the requests that are not failing are also missing cache x-cache-status: miss. Adding Traffic to help me understand this information, is it possible that the cache layer is not sending the proper response headers?

@Mholloway I'm almost finished with the setup, but after changing the web-proxy for proton, I'm getting 504 errors even though the services works perfectly with internal requests, did you have the same experience?

As of now, third-party usage of WMF map tile server is blocked due to past outage. Please take a look into https://lists.wikimedia.org/pipermail/maps-l/2020-March/001713.html for more info

@Em sorry for the confusion, I suggest that you track T254014: Reimport OSM data on eqiad in order to have more accurate feedback regarding this fix.

@Mholloway after changing the puppet configuration for the service, does the service boot automatically? Where can you find the logs?

Moving Template Issues related tasks to the tracking column, please ping us if you think there is anything else that we should act on.

Moving Template Issues related tasks to the tracking column, please ping us if you think there is anything else that we should act on.

Moving Template Issues related tasks to the tracking column, please ping us if you think there is anything else that we should act on.

It seems that the dashboard is not having a problem in catching errors that restbase dashboard does, so this task will be considered invalid.

Now that mobileapps is being moved to k8s, this seems to be supported now. @akosiaris can you confirm that information?

In T255475#6269305, @MattCleinman wrote:

One possible solution: PCS checks for {{List has been split| and calls subsequent pages if found. It then stitches the pages together into one complete page to return to mobile clients.

In T240989#6244413, @kostajh wrote:

In T240989#6233275, @kostajh wrote:

@Jdforrester-WMF I started working on a patch for this but have realized that we might need to integrate NodeJS projects (or at least mediawiki/services/push-notifications) into the codehealth pipeline in a different way than we've done for Java and MediaWiki extensions + core.

push-notifications is using a pipeline, so should we be adding configuration to its .pipeline/config.yaml and .pipeline/blubber.yaml files to handle reporting to SonarQube as part of the pipeline build? Or should we go with the path of defining a project + job-templates as the current patch is proposing to do?

Since are you are already using the pipeline, and because that is different from how the other projects are setup, I think we should try to implement the codehealth check in the pipeline. Or at least consider doing it that way.

You'd want to do something similar to what the above patch proposes (generate test coverage, then trigger a call to sonar-scanner which pushes the analysis to SonarQube, and make sure the credentials are available via an environment variable). The only problem I see is how to use the sonar-scanner CLI from within the pipeline context. If I understand what's happening in blubber.yaml, all the operations are happening in the context of a single docker image, so you'd need a script that would download the sonar-scanner.zip (https://docs.sonarqube.org/latest/analysis/scan/sonarscanner/) and then install and run it; I checked and the sonar-scanner binary should run on docker-registry.wikimedia.org/buster-nodejs10-devel.

Benchmark is done, if necessary a new benchmark is needed after review, please re-open it.

Closing this as resolved since the PCS part is done and the remaining work will be tracked at T256491: Improve Accept-Language header handling in RESTBase

This required a change in restbase: see https://github.com/wikimedia/restbase/pull/1271

In T257187#6282174, @thcipriani wrote:

In T257187#6280782, @jcrespo wrote:

@thcipriani I believe you will be the service owner approving this access. Can you work with the requester (or assign one of your direct reports to work with him to understand better the needed access) and once it is clear, approve if it proceeds?

• For working on mobileapps deploy-service will be needed -- +1 from me.
• deployment is primarily for mediawiki deployers to perform admin tasks (restarting apache and php), so I'm not clear if/why that's needed: is the intention to perform backport/config deploys @Jgiannelos?

The non-deployment groups: I don't have much insight into/am not the service owner.

In T218217#6263001, @Physikerwelt wrote:

I do not really understand what needs to be done within mathoid. Mathoid has two dependencies

"swagger-router": "^0.7.4",
"swagger-ui-dist": "^3.25.0" (optional, because it was incompatible at some point in time and has not been working for me since then)

Since IMHO nobody ever uses the swagger-ui in its current form, we can just drop these and reintroduce standard swagger-ui components if needed. When I tried that I realized that https://github.com/wikimedia/swagger-router/blob/797375ac0e80ba913a08787b17c72ef303042a15/lib/uri.js is used quite a lot in the tests. If this is also the case in other libraries, maybe it would be worth the effort to describe the migration path for URI in this ticket, so that not every library goes its own route.

@Jgiannelos and @Mholloway in the latest patch I swapped the @parse/node-apn library with the upstream one, and proxy works fine, I think because it's not using HTTP/2 and HTTP/1.1 have proxy functionality in place.