Ok, the code is life on all wikis, now it's time to start gradually enabling it. First step - enable in labs and I've created the following config change for that: https://gerrit.wikimedia.org/r/#/c/368206/

So EventBus/Change-Prop is not enabled on those wikis because RESTBase is not enabled, and as CP right now is mostly used to update restbase, there was no need to enable EventBus or CP. However, as EventBus is going to replace the JobQueue eventually, we need to enable it on all wikis (or close to all wikis). Technically, even if we don't need or want RESTBase on a wiki, we can craft special rules for change-prop that will directly hit Parsoid.

I would guess that the issue would be present on all wikis where EventBus is not enabled: https://github.com/wikimedia/operations-mediawiki-config/blob/master/wmf-config/InitialiseSettings.php#L19000

After the patch above is merged, do git pull on vagrant repo to pull the latest puppet, and after running vagrant provision RESTBase should start working again.

Errr... Accidentally merged the issues wrong way.

This is another symptom of T171592

Merged to the next-gem branch. Resolving.

PR: https://github.com/wikimedia/restbase/pull/837

In T170997#3450399, @Arlolra wrote:

Considering T98995, it's probably fine. But if we decide to do that, we should also remove the functionality from Parsoid altogether.

Right now we can get away from this by using the timeuuid as an index in the timeline tables as we can create TIDs for arbitrary dates. However, the plan for the key_value buckets was to start simply overwriting the content, so this automatic generation of a tid will get in our way..

@JoeWalsh RESTBase uses / for routing, so all the titles in the request should be URI-encoded like encodeURIComponent(title). So the / becomes %2F

This looks exactly like the concept of REST HATEOAS - the response here is the driver for the client to discover more APIs.

We don't really have any place where we use 'null' meaningfully yet, but I do agree it might be the case in the future. I'll decline my own task :)

@Ottomata I was more wondering if we can just treat null as undefined generically and whether that's a good idea. So that if the field is optional, then null is allowed by default

Ok, seems like something was corrupted in my vagrant setup. After deleting the virtualenv and reprovisioning it finally started to work correctly.

@Krinkle Interestingly, for me vagrant git-update also works with my patch.

There's a line in the top description specifying Apache2

The git-update portion (as usual) failed at RESTBase with Maximum call stack size exceeded . But then inside the vm, the following worked.

Found a workaround that seems to work for me - downgrading npm to version 2. Uglyish solution, I know, but I couldn't find anything nicer in tens on npm bugs related to this.

@GWicke This is still happening for me. I've tried today to test various npm versions and find answers on google, but no luck for now.

In T163380#3427329, @Tgr wrote:

What's the desired end state? I imagine you won't use JobQueue::pop / JobQueue::ack as using a hook wouldn't make sense then. So JobQueueEventBus will push to kafka on push, everything else would be a noop, and something else would be responsible for actually running the jobs?

Here's the presentation from the discussion of the options on the Developer Summit 2017: https://commons.wikimedia.org/wiki/File:Asynchronous_processing_on_the_WMF_cluster.pdf

Redis was added to ChangeProp nodes and is already successfully used for blacklisting unparseable pages. This is done.

In T169930#3426997, @bearND wrote:

I believe the issue is really that it uses normalized titles when it should be using db titles (getPrefixedDBKey) instead. (Underscores instead of spaces)

I've heavily edited the task description to incorporate input from @GWicke and @mobrovac

In T163380#3426174, @GWicke wrote:

IIRC the other option you looked into before was to create a "wrapper" JobQueue class that delegates to Redis *and* the new backend class instances?

Hm, not as trivial as I thought. In EventBus we rely on the core RecentChange behavior, using the default formatter and sending it to the EventBus. WE could generically add parsedcomment to the core RecentChange, but I don't think that's a good idea - inside MediaWiki the comment could be easily parsed if needed. WE could add some custom logic in the formatter, which I suppose is a better way to go.

It seems so from the code Lemme try it in vagrant

So, in my understanding, @Ottomata is -0.5, @mobrovac is also -0.5, I'm +0.5 and I guess @Nirmos who requested this is +1.0. Overall we have +0.5 for including. Did I summarize correctly?

In T170145#3422551, @mobrovac wrote:

I don't have a firm stand on this, but it seems like verbose information that is already present in the comment field. Should we then get rid of comment?

We should also take into consideration the development cycle with mounted paths. In case of development, the code is over mounted on top of the sources from inside the container, and the entry point changes to install new node_modules (or update old already installed) and then start the service with the config, that's also over-mounted from the cloned repo. So we need something like /bin/reinstall_deps_and_start

In T170145#3421563, @mobrovac wrote:

We don't include any HTML-formatted content in our events, so I'm with you: I don't think we should include parsedcomment.

In T158100#3415821, @mobrovac wrote:

Yes, the revision visibility change :) One can change the visibility of various parts of a revision, and without exposing the revision in any way in the REST API, I don't see how we can update that.

Setting this to blocked until we get more info when (if) this happens again

We've enabled automatic blacklisting for all the derived content updates, so even if this issue happens again it won't kill RESTBase, so for now I'll stop investigating the root cause as we clearly don't have enough information

The root cause identified - somehow ChangeProp config in beta cluster got pointed to the production RESTBase instance. The patch above fixes that.

@Jdlrobson created T169912 to track not working beta cluster as it seems unrelated to this. Will have a look today.

This is true. I'd hope that any RESTful service running on a non-English Wikipedia to accept Talk:Foo and respond with 303 See Other [0] with the appropriate Location HTTP header. The client would then request the resource pointed to by that header.

Deployed and confirmed to work. Resolving the ticket.

We can add support for that server-side if needed.

Any updates on this?
This endpoint came up as a possible solution to T168625. We are basically recreating the logic of the intro field in the MCS endpoint...

@mobrovac I've proposed that option to match the Parsoid API, but providing a GET endpoint works too.

Filed a subtask for Parsoid to figure out correct redirects in case only the title is provided but not the revision. This is blocked on it for the time being.

Parsoid accepts just title/revision in it's wikitext/to/lint API, so all we need to do it to make wikitext an optional parameter as well, and check that either wikitext or a title is provided. Easy.

The task descriptionis brutally outdated, we've implemented a very different approach to dependent pages updates. However, this still needs to be supported an PR for it is awaiting mediawiki train deployment: https://github.com/wikimedia/change-propagation/pull/191