Page MenuHomePhabricator

Change propagation for Flow
Open, Needs TriagePublic

Description

When content that a Flow post references (e.g. a link or template) changes, the Flow post needs to re-render its HTML.

For example, when a template is created, the prior red link needs to re-render.

We somewhat work around this for standard red links, since they're "fixed" (re-rendered) at view time. However, if T39902: RFC: Implement rendering of redlinks in Parsoid HTML as post-processor were implemented, we could remove this "fix", and use standard re-rendering for this too.

There are various approaches to this:

  1. Switch to RESTBase and handle event propagation similar to them: T94574: Switch Flow from ExternalStore to RESTBase
  2. Use EventBus somehow.
  3. Have other code call into Flow giving us affected pages (Topic:123 uses Template:Cn, Template:cn changed) (Flow does update the standard link tables as well, so this shouldn't require that much effort), then we figure out from our internal link tables what to do (that topic's summary transcludes Templates:Cn, re-render topic), probably combined with 1 or 2.

Event Timeline

Mattflaschen-WMF raised the priority of this task from to Needs Triage.
Mattflaschen-WMF updated the task description. (Show Details)
Restricted Application added a project: Collaboration-Team-Triage. · View Herald TranscriptFeb 4 2016, 6:30 PM
Restricted Application added subscribers: StudiesWorld, Aklapper. · View Herald Transcript

My first thought is to tackle this in two layers:

  1. Figure out which pages / flow boards need to be updated in reaction to template / image changes and page creations, using the regular MediaWiki Link tables.
  2. Within a Flow board, figure out which posts need to be updated, and do so.

We have a lot of infrastructure for 1), including the RESTBase update stuff & EventBus. If we could figure out that a specific page is a flow board (which would require knowing the content model, which is currently not in eventbus), we could call a Flow 'update' API providing the board name & changed dependency. Flow could then take care of 2), using its internal link tables.

DannyH removed a subscriber: DannyH.Feb 5 2016, 5:52 PM

We have a lot of infrastructure for 1), including the RESTBase update stuff & EventBus. If we could figure out that a specific page is a flow board (which would require knowing the content model, which is currently not in eventbus), we could call a Flow 'update' API providing the board name & changed dependency. Flow could then take care of 2), using its internal link tables.

This makes sense.

My only concern is whether the 'update' API could be authenticated such that only RESTBase/EventBus/something internal can call it. I would prefer that, because old HTML versions are just stored in External Store forever (or at least until we do a "cleanup orphan" pass, which is implemented for wikitext, but not for Flow yet). So we don't want spammy 're-render' requests.

We have concepts of system users/bot users we could maybe use. (There is also authentication for the job queue (SpecialRunJobs::getQuerySignature) using a different mechanism).

We could use the ping-limiter, but I think authenticating it system-only might be better.

Always problematic -- I've do a dummy edit to update templates on my Flow board description.

Restricted Application added a project: Growth-Team. · View Herald TranscriptJul 18 2018, 6:53 PM
SBisson moved this task from Inbox to Triaged but Future on the Growth-Team board.Jul 20 2018, 5:10 PM