Change Details

There's a configuration block in the change propagation rules ( https://github.com/wikimedia/mediawiki-services-change-propagation-deploy/blob/master/scap/templates/config.yaml.j2#L327 ) dedicated to exhaustively listing supported (wiki, model) pairs. Presumably, that matrix is already duplicated in several places. It'll be easy to reuse that if we write the change propagation filter as a lightweight glue module Also: the `precache` GET parameter seems to have a side-effect, which is not very RESTful. We should replace that with a PUT? It doesn't seem like the endpoint needs to receive a list of models, either--the notification is of a new revision, and the choice of what actions to take is up to the backend. (Which is always, evaluate all enabled models on each new revision.)

# Problem There's a configuration block in the change propagation rules ( https://github.com/wikimedia/mediawiki-services-change-propagation-deploy/blob/master/scap/templates/config.yaml.j2#L327 ) dedicated to exhaustively listing supported (wiki, model) pairs. Presumably, that matrix is already duplicated in several places. It'll be easy to reuse that if we write the change propagation filter as a lightweight glue module Also: the `precache` GET parameter seems to have a side-effect, which is not very RESTful. We should replace that with a PUT? It doesn't seem like the endpoint needs to receive a list of models, either--the notification is of a new revision, and the choice of what actions to take is up to the backend. (Which is always, evaluate all enabled models on each new revision.) # Solution Implement `/precache` endpoint in ORES that will be able to receive a request for all changes and will internally work out that (1) it has contexts relevant to the change and (2) which models should be precached for it.

# Problem There's a configuration block in the change propagation rules ( https://github.com/wikimedia/mediawiki-services-change-propagation-deploy/blob/master/scap/templates/config.yaml.j2#L327 ) dedicated to exhaustively listing supported (wiki, model) pairs. Presumably, that matrix is already duplicated in several places. It'll be easy to reuse that if we write the change propagation filter as a lightweight glue module Also: the `precache` GET parameter seems to have a side-effect, which is not very RESTful. We should replace that with a PUT? It doesn't seem like the endpoint needs to receive a list of models, either--the notification is of a new revision, and the choice of what actions to take is up to the backend. (Which is always, evaluate all enabled models on each new revision.) # Solution Implement `/precache` endpoint in ORES that will be able to receive a request for all changes and will internally work out that (1) it has contexts relevant to the change and (2) which models should be precached for it.