Official WMF Phabricator work account. @xSavitar is my volunteer account. Use that for non-WMF related things.
User Details
- User Since
- Jan 7 2020, 11:30 AM (168 w, 3 d)
- Availability
- Available
- LDAP User
- Unknown
- MediaWiki User
- DAlangi (WMF) [ Global Accounts ]
Yesterday
Thu, Mar 30
Thank you for this list Joe. It's very useful and helpful.
@daniel and I spoke about this today in our sync call. I'll be investigating which services are using parsoid via RESTBase. Once we have that list, we can then begin migrate the services to access Parsoid via core endpoints directly.
Tue, Mar 21
After a conversation with Daniel yesterday, and a few findings, there are some points to consider:
Mon, Mar 20
I've spotted a patch about variants here: https://gerrit.wikimedia.org/r/c/mediawiki/services/chromium-render/+/897192, so reopening this issue for some more investigation.
This is covered in the patch that covers T329821: HTTP response headers compatibility for "Proton + RESTBase" vs "Proton directly"
Proton just calls MediaWiki and delegates redirect mechanisms to it so in this case, redirects such as:
Wed, Mar 15
Thank you @pmiazga for joining me in the deployment. And thanks to @Jgiannelos for the guidance and help, and getting patches merged. 🎉
Deployed to codfw and other (staging, eqiad) environments. Resolving this now.
Thu, Mar 9
@cscott, I've been thinking about this and so far, when it comes to proton, things happening in the MW world are all MW based. All proton does is calls MediaWiki directly when it comes hitting a page to render it's PDF.
I had a detailed conversation with Piotr yesterday about these 3 and it turns out we can ignore them. Below is our reasoning:
Mon, Mar 6
New image of proton: https://integration.wikimedia.org/ci/blue/organizations/jenkins/trigger-chromium-render-pipeline-publish/activity/ (2023-03-06-192059-production) deployed and tested on enwiki. Everything works fine.
Relevant patches:
The following response headers are still in TODO phase: etag, content-location and server.
Thu, Mar 2
Feb 22 2023
@Jdforrester-WMF, I've marked the repo as read only and prepended the appropriate message. Let me know if you need anything else sir!
@Jgiannelos & @pmiazga, can you confirm with me that right now, Proton running in isolation follow redirects because that's the default MW way except explicitly specified to not follow redirects?
Testing locally: curl -X 'GET' http://mediawiki.development.instance:3030/en.wikipedia.beta.wmflabs.org/v1/pdf/User:XSavitarTest%2Fsandbox%2FRestbaseProton/a4/desktop -H 'accept: application/pdf' --output ~/Desktop/RedirectTest.pdf seems to reveal that Proton directly follows redirects when trying to print the article as this seems to be the normal mediawiki behavior except the redirect=no is set in the URL.
RESTBase follows redirects so what Proton gets is the article of the target page to print. From testing locally, this is still the case.
Feb 16 2023
Right @hnowlan, from within the network, I can do that. Thanks! The external endpoint is not needed for now.
The difference in the response headers that need to be added or modified for direct Proton to be compatible with how RESTBase + Proton works is:
@pmiazga, the response gotten from hitting proton directly needs to be compatible with RESTBase responses. I see Proton has less stuff but some of them are already exactly the same like RESTBase responses but it lacks more information. I'll have to make sure we add more things to Proton's response headers.
Feb 15 2023
Feb 6 2023
Jan 27 2023
Jan 26 2023
Jan 9 2023
Dec 13 2022
@Arlolra, I can also confirm that this is working on Group 1 (example: enwikibooks) and Group 2 (example: enwikipedia) which are still both on .13 now.
Nov 23 2022
Nov 22 2022
Oct 28 2022
I was able to reproduce this locally and it happens even if you don't convert from HTML -> Wikitext. From source mode directly to HTML causes this problem. I'm working on a fix. Let's see how it goes. Thanks for reporting @Krinkle. The regression was introduced by the DualParsoidClient: https://gerrit.wikimedia.org/r/c/mediawiki/extensions/VisualEditor/+/844465.
Oct 25 2022
Oct 20 2022
No, they are not equivalent. We have to modes of accessing the parser cache, they need to be tracked separately.
@daniel, I think the below keys:
htmlinputtransformhelper.get-original.with-renderid.stash-miss.paser-cache-miss htmlinputtransformhelper.get-original.with-renderid.stash-miss.paser-cache-hit.match htmlinputtransformhelper.get-original.with-renderid.stash-miss.paser-cache-hit.mismatch
Oct 19 2022
Oct 4 2022
Sep 28 2022
Sep 27 2022
Sep 7 2022
Sep 3 2022
Aug 28 2022
Aug 24 2022
Aug 21 2022
Aug 18 2022
Aug 17 2022
Now done!