Yes yes, we need it! All the JobQueue stats are there, so please don't remove it.
This root cause here might actually be T238161: [Regression pre-wmf.6] Cannot create a new page on Beta cluster shows error "Error contacting the Parsoid/RESTBase server (HTTP 500)" but in order to confirm it, we'd need someone to answer the above questions:
Lol, I know you're always interested in discussions involving bikes of any type :P
@jlinehan your patch needs a manual rebase. Once you do that and address the comments, please move this task back to the External Review Needed column on the Clinic Duty board and we'll take another look.
The above patch fixes the issue. I have applied it in beta and tested it, and it works as advertised - now pages can be created using VE.
Thank you, @Daimona for the backports (I managed to forget to leave a comment about it being needed given the messages in the code). All three patches have been merged into REL1_34 now!
There is something strange going on. The stack trace is identical to T237666: Parsoid/PHP fails for transforms for new pages with slashes in the title:
That makes sense, I guess, since, as you point out, the main point of contention is write access (or the update workflow, to be more precise). We could set up an intricate ACL system and put it all in one repo, but that smells of over-engineering in this instance. As for the names, I'd suggest event-schemae/system and event-schemae/user.
Indeed we can!
Yup, still happening at a rate of approx 100 errors/hour.
Tue, Nov 12
PR #48 fixes this.
This is actually a problem with the underlying preq library, which doesn't decode the body properly in cases of error. I shall fix that.
To be deployed this week.
Mon, Nov 11
Fri, Nov 8
Indeed all's good here.
I would strongly advise against the above patches (PS 549629 and PS 549633). There is special logic in RESTBase for handling the transition period; it allows us to (i) test Parsoid/PHP; and (ii) selectively switch projects over (for a detailed explanation of the modus operandi cf. the description of PR #1207). However, this logic is bypassed if the client supplies the X-Parsoid-Variant header. This possibility was given to clients exclusively for the purposes of them being able to test and play with Parsoid/PHP at their own pace, but was never meant to be used everywhere. Therefore, VE setting X-Parsoid-Variant everywhere would interfere with our transition plans and would leave little room for quick reverts.
Thu, Nov 7
Wed, Nov 6
PR #1213 accomplishes this.
Thank you, @matmarex, for taking the time to look into this!
+1 for the logic and the patch. I added @matmarex to the patch as he has been doing extensive VE <-> RB communication debugging lately so he'll be able to tell you for sure if there are other places where the header should be added.
Tue, Nov 5
Not sure this should be closed. RunJobs.php and RunSingleJob.php are still present (and used from) mediawiki-config, and not mediawiki-core
As @bd808 points out, wikitech is a special wiki, and because of its set-up outside the main WM cluster, RESTBase is not available for it. Hence, any wikitech.wikimedia.org/api/rest_v1/-prefixed URL will 404.
Tue, Oct 29
(moving to Blocked on the CPT board until the CR is ready to be re-reviewed)
Ok so the constants we are using in code are present in libcurl, so that's not it. The next step would be to inspect the log entries of your MW instance.
@santhosh is the cx testing server running PHP7? There were changes introduced to the curl layer in MW that require PHP7+ to run.
@santhosh try again now :)
HTTP 0 would suggest that there was a service crash of some sorts in the pipeline and as a result a malformed response was returned (hence the 0 status code). But, in order to investigate more, we'd need a reproduction case. Also, some questions that spring to mind: