Lowering the priority as we are out of the woods for the time being. Jobs are being processed now, but it will take a while to catch up with current events (at least 24h form now).

FYI, I already +1'ed the patch, but @jcrespo raised some questions on the PS that I think should be addressed before merging.

@daniel Gerrit 552564 which is awaiting review depends on a WIP patch, so moving back to Ready.

In T206283#5715143, @Krinkle wrote:

In T206283#5666481, @mobrovac wrote:

@Krinkle @aaron Gerrit 522234 has been merged. As for Gerrit 497537, two things are missing:
(i) Amir had a concern on the PS that went unaddressed;

OK. I've signed the Gerrit change back over to @aaron.

RESTBase (and other services) are alerting because we want to be sure that we catch problems visible by external users. While it does sometimes introduce false positives (the inverse is true too - RB alerts if back-end services alert), it is better to have more alerts than none due to convoluted logic or fixtures.

I should note that most of the errors appearing there originate from ChangePropagation, so they seem like genuine ones (given that Parsoid/JS don't spit out an error for 99% of these).

PR #1226 adds the title component.

Mirroring had to be disabled due to too many errors being emitted by Parsoid/PHP. Once the fixes for it have been deployed, RESTBase can de re-set up to mirror the traffic. I have prepared everything for it, all that needs to be done is to deploy restbase with scap deploy -f from deploy1001.

RESTBase is now mirroring all html2html requests to Parsoid/PHP.

Yes, the time-out is there on purpose. All jobs share it. We cannot increase it on a per-job basis, though, only for job runners as a whole. Why does a page rename in this instance take so long in the first place? I think this is the angle that should be looked at.

As of the RESTBase deploy, these errors do not appear any more. Resolving.

Ok found the bug. The problem was that the filter routine that executed the actual conversion was loaded twice. PR #1219 fixes this.

I've established that it's definitely RESTBase's fault: for some reason, when the revision is provided, it asks for the conversion twice, but the second time it provides the content returned to it by Parsoid for the first conversion request. I'm still investigating why and how that happens. To be continued.

@ssastry note that if you let it ride the train, that means setting switching back for two weeks (this week + next week for the train). Ideally, you may want to put the patch up for SWAT as soon as it gets merged into master (either Tuesday or next Monday).