This would allow to make sure the stream is not empty on either DC, facilitating refine ingestion.
Note from this slack discussion with @Jgiannelos : The URI used in the canary-events should be crafted so that changeprop and cache-invalidation don't stumble upon them.
| Subject | Repo | Branch | Lines +/- | |
|---|---|---|---|---|
| Update ext-EventStreamConfig | operations/mediawiki-config | master | +1 -1 |
The canary event is generated from the first event schema examples.
If we enable them now, a resource_change canary event will look like:
$schema: /resource_change/1.0.0 meta: dt: '2026-02-01T00:00:00Z' stream: resource_chnage uri: /example/resource/uri domain: canary
See also:
I think it doesn't matter on the event consumer side to have a canary event like that. Worst case our invalidation is going to point to a non existing entry in a cache.
The amount of events we are talking about won't cause any load problems.
Change #1234457 had a related patch set uploaded (by Joal; author: Joal):
[operations/mediawiki-config@master] Update ext-EventStreamConfig
Change #1234457 merged by jenkins-bot:
[operations/mediawiki-config@master] Update ext-EventStreamConfig
Mentioned in SAL (#wikimedia-operations) [2026-02-02T14:06:26Z] <lucaswerkmeister-wmde@deploy2002> Started scap sync-world: Backport for [[gerrit:1234457|Update ext-EventStreamConfig (T415638)]]
Mentioned in SAL (#wikimedia-operations) [2026-02-02T14:08:19Z] <lucaswerkmeister-wmde@deploy2002> lucaswerkmeister-wmde, joal: Backport for [[gerrit:1234457|Update ext-EventStreamConfig (T415638)]] synced to the testservers (see https://wikitech.wikimedia.org/wiki/Mwdebug). Changes can now be verified there.
Mentioned in SAL (#wikimedia-operations) [2026-02-02T14:17:10Z] <lucaswerkmeister-wmde@deploy2002> Finished scap sync-world: Backport for [[gerrit:1234457|Update ext-EventStreamConfig (T415638)]] (duration: 10m 45s)