@aaron I have started looking into it, and I am not sure how one can get an instance of ChronologyProtector in the code that needs it. The only place I can see that uses ChronologyProtector is LBFactory class, but getChronologyProtector() is protected there, so it's impossible to get it from outside, and there are no other code anywhere that work with it. What would you advise to do in this case? How can one get ChronologyProtector::getClientId()?

I think you can just add a method, similar to LBFactory::getChronologyProtectorTouched, that exposes the client ID, maybe call it LBFactory::getChronologyProtectorClientId();

Change 504815 had a related patch set uploaded (by Smalyshev; owner: Smalyshev):
[mediawiki/core@master] Add getChronologyProtectorClientId() to LBFactory

https://gerrit.wikimedia.org/r/504815

Change 504819 had a related patch set uploaded (by Smalyshev; owner: Smalyshev):
[mediawiki/extensions/EventBus@master] Add chronology_id field to event

https://gerrit.wikimedia.org/r/504819

Change 504826 had a related patch set uploaded (by Smalyshev; owner: Smalyshev):
[mediawiki/event-schemas@master] Add chronology_id field

https://gerrit.wikimedia.org/r/504826

Hm, can we add some more documentation, especially to the field in the event schema? I'm not familiar with ChronologyProtector, and googling around for docs isn't yielding much.

This is probably the request for @aaron, he knows the most about it.

Another question for @aaron as well - If we start storing this chronologyprotector field in kafka etc. that means it can survive longer and no longer has an expiry like we do for cookies. I vaguely recall an issue in the past where clients that kept the value too long caused subsequent requests to stall for many seconds as MW mistook the unknown value for a value that hasn't appeared yet.

It may've been mitigated already, but if not, we'll need to sort that out before this goes live.

@aaron Is there any docs how to use the client ID on the client side? I see there's support for cpPosIndex cookie which is $index@$time#$clientId but if I have only client ID that is not going to help me. So I am not sure how would one use it - I can't find any trace of ChronologyClientId HTTP header.

In T212550#5124280, @Krinkle wrote:

Another question for @aaron as well - If we start storing this chronologyprotector field in kafka etc. that means it can survive longer and no longer has an expiry like we do for cookies. I vaguely recall an issue in the past where clients that kept the value too long caused subsequent requests to stall for many seconds as MW mistook the unknown value for a value that hasn't appeared yet.

It may've been mitigated already, but if not, we'll need to sort that out before this goes live.

That was cpPosIndex for cookies, which was changed to include timestamp/clientId so that old values are ignored server-side. Use of client IDs alone will never cause wait delay on the position store itself, which is fine for this sort of EventBus use case; the DB changes and kafka enqueue happen in the master DC and the jobs run in the master DC as well, so there is no need to wait on cross-DC position store replication. By not doing so, it also avoids any risk of weird cases causing wait timeout delay.

In T212550#5124323, @Smalyshev wrote:

@aaron Is there any docs how to use the client ID on the client side? I see there's support for cpPosIndex cookie which is $index@$time#$clientId but if I have only client ID that is not going to help me. So I am not sure how would one use it - I can't find any trace of ChronologyClientId HTTP header.

Right, I'll patch Setup.php to use the header if cpPosIndex does not already contain it via the cookie. I thought it did this already, but apparently not (probably since nothing uses that pattern yet).

Change 505328 had a related patch set uploaded (by Aaron Schulz; owner: Aaron Schulz):
[mediawiki/core@master] Use "ChronologyClientId" HTTP header when the ID is not already in "cpPosIndex"

https://gerrit.wikimedia.org/r/505328

Change 504815 merged by jenkins-bot:
[mediawiki/core@master] rdbms: add getChronologyProtectorClientId() to ILBFactory

https://gerrit.wikimedia.org/r/504815

Change 505328 merged by jenkins-bot:
[mediawiki/core@master] Accept new "MediaWiki-ChronologyClientId" HTTP header

https://gerrit.wikimedia.org/r/505328

I guess my comment here got missed? https://gerrit.wikimedia.org/r/c/mediawiki/core/+/505328#message-f9c4c6e4cf0235e8dfa743ced1dc17ac6ca1dd21

Hello everybody, I am investigating https://phabricator.wikimedia.org/T223310, namely the one of the Redis MainStash being constantly hammered by GET to global:Wikimedia\Rdbms\ChronologyProtector since after the deployment of 1.34.0-wmf.3. Is it related to anything done in this task? I thought it was https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/EventBus/+/504819/ but it is still not merged..

Change 504826 merged by Ottomata:
[mediawiki/event-schemas@master] Add chronology_id field

https://gerrit.wikimedia.org/r/504826

Change 504819 merged by Ppchelko:
[mediawiki/extensions/EventBus@master] Add chronology_id field to events.

https://gerrit.wikimedia.org/r/504819

Change 524349 had a related patch set uploaded (by Smalyshev; owner: Smalyshev):
[wikidata/query/rdf@master] Add Chronology Id support for change events

https://gerrit.wikimedia.org/r/524349

Change 524349 merged by jenkins-bot:
[wikidata/query/rdf@master] Add Chronology Id support for change events

https://gerrit.wikimedia.org/r/524349

In T212550#5369348, @gerritbot wrote:

Change 524349 merged by jenkins-bot:
[wikidata/query/rdf@master] Add Chronology Id support for change events

https://gerrit.wikimedia.org/r/524349

For the record, this usage was removed in T241536: Remove the use of chronology_id in wdqs-updater
https://gerrit.wikimedia.org/r/c/wikidata/query/rdf/+/578326