Thu, Jan 18
Everything has been completed and merged, resolving \o/
PR #946 bumps RESTBase's version to v0.18.0.
It seems @Pchelolo's normalisation fix did the trick. I cannot reproduce this any more, regardless of whether there is a Varnish hit or miss, so I think it's safe to assume the problem has been fixed. @Dbrant please reopen if you encounter it again.
The RESTBase side of things has been deployed.
Wed, Jan 17
I would prefer having a stable and known-to-work version everywhere rather than confining the problem to SCB
Mon, Jan 15
Citoid is not exposed to the world directly, so that URL is not reachable at all. If one wants to get the API docs, they should point their browser to http://localhost:1970/?doc. But again, this is all local, in production none of this can be seen, so I'm not sure this ticket is relevant.
Sat, Jan 13
+1 on removing it. @Ottomata ok with it too?
This is strange indeed. This part of the logic is handled by Varnish. @BBlack @ema would you be able to explain why a RESTBase-issued redirect doesn't make it through in the case no-cache is supplied by the client?
Fri, Jan 12
PR #942 brings the new versioned packages with the old names into RESTBase. It also changes back /sys/table3/ to /sys/table/.
Thu, Jan 11
Wed, Jan 10
I agree that the overall goal is to get to Wikitext 2.0, I just wasn't sure if you plan on tackling this particular issue as milestone in that path. Declining this RfC for now then and waiting on the Wikitext 2.0 one :)
@awight what is the status of this proposal? Have you been working more on collecting interest and/or working on a prototype?
The public API endpoint has been deployed.
The fix for RESTBase has been deployed.
Tue, Jan 9
PR #940 adds top-by-country to the public API. It has been merged and will go out tomorrow.
RESTBase is now alive and kicking on all nodes. Resolving.
That was supposed to be a temporary measure to test reverting a problematic commit. I enabled Puppet back on the hosts and ran it.
Mon, Jan 8
Heh, as far as I can see, the build completed, but I'm still stuck with the same problem and the same Scap version on deployment-tin as before. I tried forcing a Puppet run, but no luck:
For the rb-m-t-* packages, all looks good, except the version bumps: let's bump the minor versions, not just the patch level, as that will prevent automatic upgrades which in this case could break clients. So let's have versions 0.3.0, 0.2.0 and 0.13.0 respectively.
Sat, Jan 6
Hm, I'm still getting the same message when trying to deploy Mathoid from deployment-tin, and it seems Scap hasn't been downgraded there:
Fri, Jan 5
This is still an issue even though the params are now quoted:
This is all known and normal behaviour. When pages are deleted/moved/redirected, you are seeing these MCS logs because MediaWiki emits events for the old and new page names, all of which are processed by ChangeProp/RB and others. In your examples, the first title has been deleted, while the second correctly redirects to https://es.wikipedia.org/api/rest_v1/page/mobile-sections/Canal_12_(C%C3%B3rdoba) . What is the exact concern here?
The instance has been deleted and its puppet prefix and web proxy cleaned up.
Thu, Jan 4
Thnx for the fix. Please make it a thing to test Scap in Beta when a new version lands there.
Mathoid and RESTBase have been deployed. Let's savour this moment :)
While rendering the formulae that previously failed the check (14k of them), 202 failed to render only with the new Mathoid, and 681 of them failed to render both with the old and new versions:
All of the formulae pass the check test now with texvcinfo v0.5.2 and texvcjs v0.3.6. Thank you @Physikerwelt for the fix!
Wed, Jan 3
This is effectively blocked on moving Mathoid over.
Update: the issue was tracked down to the fact that MCS was requesting the Parsoid HTML from RESTBase in eqiad instead of codfw due to the fact that restbase.discovery.wmnet was pointing to restbase.svc.eqiad.wmnet. Because MCS requested the HTML very soon after it has been re-rendered, in certain instances it got the stale version from eqiad's Cassandra. We have switched restbase.discovery.wmnet to point to the local DC this morning, so such cases should not occur any more.
I reran the script for the check errors after deploying the fix for texvcjs, however none of the formulae passed the check. This is rather weird considering that the texvcjs package's tests contain them. We will need to investigate what is going on here. Perhaps a misunderstanding between texvcjs and texvcinfo ?
@Eevans let's move the discussion over to T183745: FY17/18 Q3 Program 7 Services Goal: Full migration to Cassandra 3. Resolving this ticket, as the quarter is done and we have completed the work we set out to do here.
Tue, Jan 2
Is this a problem with the mobile version in the browser or the native Android app?
Mon, Jan 1
Easy peasy :) Thnx for reporting @bd808!
Thu, Dec 28
For all intents and purposes, this task has been completed.