Tue, Jan 21
Mon, Jan 20
Wed, Jan 15
Nm, it is.
Let's figure out who to bug about updating the npm version in the npm-node-6-docker image.
Weird. When I do the same, I get a 302 with header Location: Carnivore.
Tue, Jan 14
Ah, OK, I see that if you are requesting directly from a mobileapps service instance, then the redirects won't be resolved and the type will indeed be no-extract. I recommend using the public REST API summary endpoint.
I just tried each of the example links in Chromium, and all came back with the expected standard type. But I notice that they're all redirects, which probably isn't a coincidence. How are you requesting these that's resulting in no-extract? Are you using the public REST API endpoints? RESTBase should be taking care of resolving redirects.
Whoops, I may be confused — I was thinking about this in the context of Suggested Edits (since I'd heard about protected suggestions being an issue there), but this task actually looks broader, if not totally separate.
The real issue here was HTML-formatted content being provided in text fields, which has long since been fixed.
Incident report is in review.
Hmm, no, that isn't right.
Ah, I see — looks like domino understands the un-quoted selectors, but webpack throws an error. Thanks for fixing that!
Mon, Jan 13
(Updated the task description since what went wrong is no longer a mystery.)
My recommendation would be to go ahead with splitting into a separate queue/changeprop rule, if that's acceptable from a service ops perspective. Relatively speaking, this is a pretty low-volume job type.
Do you have a stack trace? I'd like to better understand what's going wrong and why it only occurs on some articles.
Moving back to "needs triage" for discussion in tomorrow's team meeting. This is becoming more urgent as dependencies are rapidly dropping node 6 support.
Our dependencies are also rapidly dropping node 6 support:
For reference, here are some notes on other services using encryption within the Wikimedia production environment: https://wikitech.wikimedia.org/wiki/User:Jbond/Encryption
Tue, Jan 7
I'll poke my head in from vacationland to say one quick thing: I don't know what to make of the filename business, but one particular area I suspect may be causing trouble is how we're creating and saving multiple revisions in series in the course of handling a single API request. Maybe we're getting the expected revision ID is retrieved from a DB replica at one point and from master at another, causing a race condition?
Dec 22 2019
We could forward protection info from the MediaWiki API and allow the apps to check the user's groups against any page protections in effect, or we could simply omit pages with any kind of protection from the results. Any preference for one or the other?
Dec 20 2019
Same file, uploaded with a different name, allows 2+ tags to be saved at once.
Dec 19 2019
@Pchelolo Sounds good. We'll ignore duplicate key errors upon inserting data from these jobs, then, since they're an expected condition of using the job queue.
@Pchelolo There's one other issue that needs resolution before we can try reenabling these jobs. Separate from the immediate job queue delay caused by the use of jobReleaseTimestamp, these jobs were failing at a high rate with DB duplicate entry errors, indicating that data for the same image had already been inserted by a previous job. This doesn't make sense from the MediaWiki side, where only a single job is submitted in the UploadComplete hook for a newly uploaded file. Were these most likely retries caused by the misbehaving release timestamp, or might there be something else going wrong?
Dec 18 2019
The product requirement that's meant to fulfill is for a "waiting period" of 48 hours, so that we're not sending out labeling requests for new files that are going to be quickly deleted for one reason or another. I can imagine a few different ways of implementing this, but picked the jobReleaseTimestamp since it appeared to be available for use. I thought I'd seen at least one other existing job using the release timestamp feature, but I might be mistaken.
As for the priority change, we have already added a message to the user to indicate that a depicts statement already exists for an approved label. This task is to prevent labels with existing depicts statements from being suggested at all.
To clarify my dropping this, I/Product Infra won't have time to work on this before the quarter ends and the primary maintenance responsibility shifts to the Structured Data team.
@Pchelolo Is there a step to register the job in cpjobqueue that I missed? I didn't do any Kafka configuration at all, just set up the job in the extension.