Change Details

Since `summary` and `mobile-sections-lead` endpoints contain wikidata description, we have a rule in #changeprop that is intended to rerender summary and mobile sections once the description change. However, unfortunately we've had to set up this rule to react to `revision-create` event, so we're rerendering on ANY wikidata item change, not just description. It would be great to narrow this down, because this rerendering could create a significant load (~100 req/s) on mobile cluster, and most likely this load is unnecessary. This task is created to explore the possibilities we have to filter only revision-create events where the description change, not all of them.

Since `summary` and `mobile-sections-lead` endpoints contain wikidata description, we have a rule in #changeprop that is intended to rerender summary and mobile sections once the description change. However, unfortunately we've had to set up this rule to react to `revision-create` event, so we're rerendering on ANY wikidata item change, not just description. It would be great to narrow this down, because this rerendering could create a significant load (~100 req/s) on mobile cluster, and most likely this load is unnecessary. 100 is 2/3 of the overall mobile cluster load, so it's quite critical. The current idea is to introduce `fragments` array property into the `revision-create` event. The semantics would be the IDs of the changed sections/components. So, for wikidata description change the array would contain `wb:description` string. The change propagation would match on this. The `fragments` property is not a one off solution, it can be later reused for way more things. For example, if we included `component:lead-section` ID only when a lead section is changed, we could significantly lower the summary update rate, and improve the granularity of the mobile updates. Opportunities are endless.

Since `summary` and `mobile-sections-lead` endpoints contain wikidata description, we have a rule in #changeprop that is intended to rerender summary and mobile sections once the description change. However, unfortunately we've had to set up this rule to react to `revision-create` event, so we're rerendering on ANY wikidata item change, not just description. It would be great to narrow this down, because this rerendering could create a significant load (~100 req/s) on mobile cluster, and most likely this load is unnecessary. This task is created to explore the possibilities we have to filter only revision-create events where the description change,100 is 2/3 of the overall mobile cluster load, so it's quite critical. The current idea is to introduce `fragments` array property into the `revision-create` event. The semantics would be the IDs of the changed sections/components. So, for wikidata description change the array would contain `wb:description` string. The change propagation would match on this. The `fragments` property is not a one off solution, it can be later reused for way more things. For example, if we included `component:lead-section` ID only when a lead section is changed, we could significantly lower the summary update rate, and improve the granularity of the mobile updates. not all of themOpportunities are endless.