Perhaps enabling RESTBase there shall fix it. https://gerrit.wikimedia.org/r/c/mediawiki/services/restbase/deploy/+/635657

500 is clearly not a correct status code. 500 indicates an unknown server error, here it's a very much a known error - we were lazy and didn't implement pagination.

Ok, now it works: https://superset.wikimedia.org/superset/sqllab?savedQueryId=139

Ok, thank you for your input. I think at first I will pursue the simpler solution - look whether it's possible to remove compression and not break anything. Will try to hunt down original reasons and will write up what I discover.

I don't understand what the page_props value has to do with the ParserCache value though, why does it matter for the ParserOutput object whether one of its string values happens to use gzip encoding?

This is going to be an experiment to figure out if this is viable. In the beginning, let's try tests/features/transform/transform.js

So, the problem is that when we switch ParserCache to JSON, we loose the ability to store gzip-compressed data in page properties. T203850 already has restricted gzipping to just mysql, but it seems now we will have to eliminate gzipping from TemplateData altogether.

After deploying to beta and to testwiki revealed a bunch of non-JSON-serializable data pithing ExtensionData: https://logstash-beta.wmflabs.org/goto/de000f31b6d6abad639c7ce039917826 and https://logstash.wikimedia.org/goto/e0806c65d45b32bc0d6ca307bf9c76bc

I have enabled JSON serialization on testwiki with no issues. Moving on to group0

We are finally switching ParserCache to JSON. I think we should decline this task, or drop the VERSION entirely.

Fixed by https://gerrit.wikimedia.org/r/c/operations/deployment-charts/+/635556

Note the typo in the interface name EditPafe. Grepped the sources for EditPafe - not found ofc. OPcache corruption?

These all look good to me.

The skin is only enabled on api.wikimedia.org, so this error will not grow larger as deployment onto more groups happen. cc @cicalese

Thank you for the answers!

I guess we have to begin here.

It works! :)

We have decided to eliminate RESTBase altogether, this task is no longer valid.

Let's step back for a minute.

Seems extremely simple to add, will take 10 minutes. Perhaps a good one for knowledge sharing. Whoever picks it up, I can help.

I don't think there's anything to document here.

--start=20150622112753 for next one.

FYI: This train will contain the code switching ParserCache from PHP serialization to JSON serialization: T263579
The code is disabled by default, thus it *should* be a no-op. We have also put significant efforts into testing backward and forward compatibility for this feature, see T264397 - a new serialization testing framework was made and we added few hundred tests for various combinations of versions, cached objects etc. In case the train needs to be reverted, we've already put compatibility code in there, so things should behave well after a revert. We feel fairly confident in this change, but please be aware anyways.

https://gerrit.wikimedia.org/r/c/mediawiki/core/+/634409/6 has refactored and restored the test. If this issue returns, we can just mark it as @group Broken again.

We do not really ever purge things from the ParserCache. We do, however, update the page_touched on pages which effectively invalidate the data stored in the ParserCache. Now that we have multiple instances of the ParserCache, data is invalidated in all of them using the same page_touched mechanism.

Don't think we will end up needing this. Will reopen if we will.

The implementation of the initiative is taking us another way. No need for this.

https://gerrit.wikimedia.org/r/c/mediawiki/core/+/631565 does it

Actually, this is a more interesting issue. If EventBus extension is enabled while running tests, ALL tests start failing - the hooks get executed, the events are being created and they are being sent to a default event service which sends it to default localhost:3000... I guess EventBus extension should not start sending events to a random port when installed but not configured.

Now wmf.11 was redeployed, so now it should be ok to test.

https://stream.wikimedia.org/v2/stream/revision-visibility-change is now available.

The phase 1 from the comment above looks like a good idea. Please don't create a massive patch to do everything all at once, let's take baby steps:

• Patch to establish the infrastructure for the constraints
• Patch to migrate one or two constraints as a demo

We should probably look at that trait again and see if we can make it more 'stably' and frameworky. Perhaps we could convert it to a new TestCase base class too.

The request is that we simply mark these endpoints as "deprecated" to discourage new consumers to allow Inuka to migrate to PCS come Q3. Is this feasible with your sunset strategy?

Ok, this batch was processed correctly after we've increased the kafka garbage collection TTL for the topic.

This is deployed and ready.

This is deployed and ready.

In T264631#6521565, @eprodromou wrote:

Are we setting cache response headers differently based on whether the user is authorised via OAuth or cookie?

Additionally, we need to unblock subpages of Special:CentralAutoLogin/, in particular Special:CentralAutoLogin/start