While PR 1072 did drastically improve the performance of the onthisday end point, RB deployments were still failing (I managed to fully deploy RB after 5 attempts). Therefore, I opted to disable the check for the time being. There were no deployment failures afterwords.
Wed, Oct 17
Ah, how did I miss this? Oh, because I was looking at my local copy of the deploy repo. Thank you @thcipriani for pointing out the obvious and sorry for wasting your time.
These are fairly static node packages which really need to be recompiled only when the Node version changes, so I would vote for option (1).
Tue, Oct 16
We have downgraded Puppeteer and now all seems good, so I re-enabled the checks.
Mon, Oct 15
Removing WMF-JobQueue as we don't use JobQueueDB in production.
Note that the deploy repo is actually still used as (a) it is still deployed on SCB; and (b) it is used for deployments in Beta. We should hold off removing it until we have removed it from SCB and found a way to have it in Beta.
It takes 75 secs for Citoid in production to answer, so it seems like this is a problem either between Citoid and Zotero or Citoid and Crossref. We need to investigate more why that is.
It is normal to wither see no changes in number or to see slightly higher numbers when the process is promise-heavier. However, we are here interested in the performance of other requests when one request holds the event loop. In this case, results for other requests should be better. It is acceptable to have slightly higher latencies for the CPU-heavy request if other requests' latencies improve.
I wholeheartedly agree that doing copy/pasta for shared parts of the schemae is a bad design choice.
We could perhaps hack around it in the following way. Each time a new version of the schema is created, a sample message also needs to be committed. That message can then be checked with existing JSONSchema validators against both the new and the old version of the schema.
Sun, Oct 14
Raising priority to high as this has started happening more and more often, even during normal RESTBase operation.
Mon, Oct 8
Fri, Oct 5
Thu, Oct 4
Yup, that did the trick! Thank you, @Arlolra !
The config still doesn't seem to be working for the edge case of en.wp.org:
Wed, Oct 3
The error, as seen by RESTBase:
I agree. On the one hand, section offsets are not nearly enough requested to warrant their own table, and on the other, RB workers are currently under-utilised so we can handle the extra CPU needed to extract them from data-parsoid.
Time drifting is a known occurrence. From what I see, we have two options:
- allow it to happen and risk duplicate v1 UUIDs: the collision rate would vary with the drift, but in practice that means that some request IDs might end up with the same UUID
- use PECL's uuid library which is a wrapper around libuuid: the library does not suffer from the time drifting problem, but requires extra packages to be installed and PECL enabled.
Tue, Oct 2
The interesting part is that this doesn't happen for CP-JQ, only CP.
Fri, Sep 28
Wed, Sep 26
I've tried various things in RB but I simply can't get RB to respond with 377057.
The REST API is returning the correct, latest revision, which is 384154. It seems to me that 377057 is somehow being set by VE, as asking the REST API for a revision of a title that doesn't match the title would result in a client error (which is not the case here).
Tue, Sep 25
The first step would be to add the user/pass combo to the private puppet repo (ping @Joe @fgiunchedi cna you help out for this step?). After that we can include it in the service's public puppet profile module (I can help with that). We also need to set up the appropriate firewall rules on the x2 hosts so to make them accessible from SCB (ping @jcrespo - let's coordinate this?).
Merged and deployed.
Mon, Sep 24
Thu, Sep 20
In my mind, asking for a non-existent tid is the same as asking for a non-existent revision, and should, hence, result in a 404. You do have a good point that it might affect Visual Editor, but in practice the 24h window is more than ample time to finish an edit. We should also take into account that VE edits are commonly based off of the latest revisions which we have in the latest bucket rather than the stash one. But I agree, let's see what @Esanders thinks.
Sep 19 2018
Sep 18 2018
Sep 17 2018
Since node's semver package does not deal with .x versions well, we settled for forcing the patch component of the version to be .0.