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/
Wed, Jul 26
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
Tue, Jul 25
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
Mon, Jul 24
Fri, Jul 21
Merged to the next-gem branch. Resolving.
Tue, Jul 18
Mon, Jul 17
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..
Fri, Jul 14
This looks exactly like the concept of REST HATEOAS - the response here is the driver for the client to discover more APIs.
Thu, Jul 13
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.
Tue, Jul 11
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.
Mon, Jul 10
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
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
Fri, Jul 7
Thu, Jul 6
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
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  with the appropriate Location HTTP header. The client would then request the resource pointed to by that header.
Fri, Jun 30
Thu, Jun 29
Deployed and confirmed to work. Resolving the ticket.
Wed, Jun 28
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...
Jun 27 2017
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