Change #1206384 merged by jenkins-bot:

[mediawiki/extensions/NetworkSession@master] NetworkSessionProvider: Implement no-op preventSessionsForUser()

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

Change #1206384 had a related patch set uploaded (by D3r1ck01; author: Derick Alangi):

[mediawiki/extensions/NetworkSession@master] NetworkSessionProvider: Implement no-op preventSessionsForUser()

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

Logstash only retains data for 3 months (so mid-August). Anyway these errors happen when newSystemUser() is called, which is rare. But they are also trivial to fix - NetworkSession just needs to implement a noop preventSessionsForUser() method (since it's for system-ish users in the first place, it doesn't need to worry about preventing normal users from loggin into system user accounts).

In T406566#11252626, @Tgr wrote:

logstash

In T373826#11244407, @Tgr wrote:

T405633: Session data is authenticated, should not be an anonymous user

Unrelated to that, maybe NetworkSession should be limited to private wikis for now, to preserve resources? It's not causing any problems, but I don't think there is any benefit to being authenticated on public wikis, either? And limiting the extension to the private dblist is straightforward.

Unrelated to that, maybe NetworkSession should be limited to private wikis for now, to preserve resources? It's not causing any problems, but I don't think there is any benefit to being authenticated on public wikis, either? And limiting the extension to the private dblist is straightforward.

In T373826#11236642, @dcausse wrote:

I do see a some limited logspam with Session data is authenticated, should not be an anonymous user since sept 27.

Tentatively closing, I no longer see this warning message since September 16.
I do see a some limited logspam with Session data is authenticated, should not be an anonymous user since sept 27.
Please feel free to re-open if this ticket is useful to track some work.

I am not sure why that error is happening in the first place. If there is an existing user account, in theory NetworkSession should just provide access to it. Maybe it's some kind of race condition, with multiple NetworkSession requests trying to autocreate a non-existent account at the same time? In theory autocreation handles race conditions but CentralAuth might mess that up. If so, then this error will go away once the account exists everywhere. (The blacklist is short-lived, five minutes IIRC.)

Thanks for all the context on this!
Regarding the the session store entry is for an anonymous user, but the session metadata indicates a non-anonynmous user, I checked a few sessions from the store and they indeed mention AuthManager::AutoCreateBlacklist with an error message centralauth-account-exists. So I suspect that once this session is gone the auto-creation will fail again for the same reason?

I guess the design assumption here is that an extension like NetworkSession can't know what kind of requests will be authenticated with the mechanism it provides, and certain kinds of requests need to store session data. So it doesn't make sense for a session provider to have a "will never need to store session data" flag.

Wrt the various flags, persistsSessionId() means that the session provider is able to update the client on what session ID to use, so that's irrelvant here. persist => false isn't very well defined for immutable session providers; conceptually, you could read it as "the session hasn't been stored anywhere", except, how would the session provider tell whether the session is persisted or not? Immutable providers like NetworkSession can't access any stateful information on their own and have to rely on the session store for that.

In T373826#11121000, @Tgr wrote:

In T373826#11119581, @Eevans wrote:

Specifically, it looks like GET rate has increased by ~33%. Is this...expected?

Yeah, it happened the last time the updater was enabled, and nothing changed since then. The AbuseFilter issue we fixed was causing bogus writes, and those are mostly gone (we still have a few thousand, not sure why, but that's a drop in the bucket); it didn't affect reads.

SessionManager does a session store read at the beginning of every authenticated session, these are authenticated sessions; the same would happen if CirrusSearch did API requests in any other way, using OAuth or cookies or whatever. There isn't any way for a session provider to indicate that it doesn't need session store lookups (conceptually, session providers are responsible for session tokens in the web request and response, not for communication with the store; that is uniform across all session types).

It's also strictly speaking not true that the session store is never used meaningfully; there are some very fringe situations in which we store data there and read it back when using NetworkSession. User autocreation errors are cached in the session to avoid repeating potentially expensive user creation attempts on every request.

If we wanted to avoid reads (which, per above, isn't necessarily a good idea), once multi-session backends land, a hacky but simple solution would be to direct all session store reads/writes with a NetworkSession provider to a fake session store (HashBagOStuff). Or maybe a real but very cheap, non-replicated cache like APC.

In T373826#11119581, @Eevans wrote:

Specifically, it looks like GET rate has increased by ~33%. Is this...expected?

In T373826#11119862, @Eevans wrote:

Out of curiosity, how were these requests being satisfied before NetworkSession was re-enabled?

In T373826#11119600, @dcausse wrote:

In T373826#11119581, @Eevans wrote:

In T373826#11119314, @dcausse wrote:

After deploying: the session write dashboard remains almost empty, sessionstore rps increased but unless I'm not reading the dashboard properly latencies appear to be fine, only the buckets "<1m" and "1-2.5ms" increased.

Specifically, it looks like GET rate has increased by ~33%. Is this...expected?

The user using the NetworkSession auth mechanism can make a lot of requests, see T373826#10141552,

In T373826#11119581, @Eevans wrote:

In T373826#11119314, @dcausse wrote:

After deploying: the session write dashboard remains almost empty, sessionstore rps increased but unless I'm not reading the dashboard properly latencies appear to be fine, only the buckets "<1m" and "1-2.5ms" increased.

Specifically, it looks like GET rate has increased by ~33%. Is this...expected?

In T373826#11119314, @dcausse wrote:

After deploying: the session write dashboard remains almost empty, sessionstore rps increased but unless I'm not reading the dashboard properly latencies appear to be fine, only the buckets "<1m" and "1-2.5ms" increased.

Unfortunately the the session store entry is for an anonymous user, but the session metadata indicates a non-anonymous user are back, it's not from all the wikis, e.g. I don't see such warnings from enwiki.

After deploying: the session write dashboard remains almost empty, sessionstore rps increased but unless I'm not reading the dashboard properly latencies appear to be fine, only the buckets "<1m" and "1-2.5ms" increased.

Mentioned in SAL (#wikimedia-operations) [2025-08-26T13:57:02Z] <dcausse@deploy1003> Finished scap sync-world: Backport for [[gerrit:1182088|Revert "NetworkSession: Only enable for private wikis" (T373826)]] (duration: 13m 49s)

Mentioned in SAL (#wikimedia-operations) [2025-08-26T13:48:42Z] <dcausse@deploy1003> dcausse: Backport for [[gerrit:1182088|Revert "NetworkSession: Only enable for private wikis" (T373826)]] synced to the testservers (see https://wikitech.wikimedia.org/wiki/Mwdebug). Changes can now be verified there.

Mentioned in SAL (#wikimedia-operations) [2025-08-26T13:42:46Z] <dcausse@deploy1003> Started scap sync-world: Backport for [[gerrit:1182088|Revert "NetworkSession: Only enable for private wikis" (T373826)]]

Change #1182088 merged by jenkins-bot:

[operations/mediawiki-config@master] Revert "NetworkSession: Only enable for private wikis"

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

The AbuseFilter issue should have been fixed by rEABF65c10f5fa06f: Skip auth checks when autocreate is allowed by provider and we now have a session writes dashboard with reliable stats, so IMO good to go.

I have a use-case for which I would need this extension enabled everywhere, @Tgr @Eevans would you have objections trying to enable it again to see if the impact on kask is acceptable?

Change #1182088 had a related patch set uploaded (by DCausse; author: DCausse):

[operations/mediawiki-config@master] Revert "NetworkSession: Only enable for private wikis"

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