Just verified it in prod:

curl -v -o /dev/null restbase1017.eqiad.wmnet:7231/en.wikipedia.org/v1/page/mobile-html/Dog 2>&1 | grep cache
< cache-control: s-maxage=1209600, max-age=0, must-revalidate
< access-control-allow-headers: accept, content-type, content-length, cache-control, accept-language, api-user-agent, if-match, if-modified-since, if-none-match, dnt, accept-encoding

Thanks @BTullis i just verified i now can run queries in superset.

In browser developer tools it looks like the issue is coming from a custom css rule for dark theme that adds background-color=inherit to the seat diagram template output.

Can I also get access to superset? I can login and everything but, I need some more permissions to access the same data sources for example I have access in hue.

From ptwiki android data:
https://docs.google.com/spreadsheets/d/1DbDC911fPLF0IrC8vev-fvuERzZ4FAEKISREMp2RtE4

We deployed yesterday so latest chrome should be in prod.

I tried the PCS output for dark theme here:
https://en.wikipedia.org/api/rest_v1/page/mobile-html/User%3ARummskartoffel%2Foverlapping_ref_highlight?theme=dark

Thanks, I just verified that I have ssh access and followed the steps for kerberos from the email.

Just verified that storage is disabled on ptwiki on prod.

For varnish config I would defer to @Joe or @akosiaris if we have any special treatment for etag headers.
From a quick look at changeprop we don't send any purge events for /page/pdf so I assume that cache-control will be good enough.

In T277059#8632997, @cscott wrote:

The patch was applied to page bundles, but it appears the bug is with the summary endpoint? I'm a little confused. AIUI the title redirection should happen in core, and in common for all endpoints, and it's not clear a patch to do that has landed yet.

Outgoing calls are already logged with debug enabled.

There is an open discussion around using a standalone instance of benthos near mobileapps service to handle events in order to move away from the changeprop centralized handling.
Are there any updates on that @Joe ?

From the criteria mentioned:

• ptwiki is group 1, low traffic (in terms of mobile-html)
• same for fiwiki

Related tickets and patches:
https://phabricator.wikimedia.org/T329592
https://gerrit.wikimedia.org/r/c/mediawiki/core/+/887997
https://github.com/wikimedia/restbase/pull/1315

I just re-run the tests and looks like the relevant test is passing now. Thanks!

Regarding headers:

I am still getting this error both on tests and when i try to login:

Ok tests are passing now. Thanks again!

Thanks @Physikerwelt @taavi for sorting things out!
Service now looks like its running but i am getting a different error related to SSL:

I am not sure about the specifics on this deployment but maybe its worth checking docker prune to cleanup old unused images/containers:
https://docs.docker.com/engine/reference/commandline/system_prune/

From the CI on restbase that is using beta cluster I am getting this error for mathoid:

We still have some docs pending in order to close this ticket.

We send a null edit to the template that regenerated the summary endpoint pages that transclude it.
In case of a single page, a purge event or a purge action would also trigger a pregeneration on the APIs.

Closing this one after: T329532

Closing after T329532

This ticket looks related: https://phabricator.wikimedia.org/T325623
I would prefer to have a more systematic approach like the one in the WIP patch from @Dbrant rather than manually improving lazy loading.
@Tsevener is this something we can do in iOS too?

Here are some numbers for PCS fetch latency on testwiki:
https://grafana.wikimedia.org/goto/1_3X8R1Vz?orgId=1

I think a good starting point to test PCS related endpoints is to setup the following routes for mobileapps:

For android specifically it looks like the problem is with the summary URLs:
From android studio:

• When I click any sr-el link it through this error
• For example for: https://sr.wikipedia.org/api/rest_v1/page/summary/Pekara