Moving a Slack convo here to phab.

@Ottomata wrote

I’m not sure if you want to just remove the user-agent-collection logic there, or if you want to implement the same logic that eventgate does, where it checks a config to see if it should set user-agent.
I think for your purposes, you can remove it and rely on agent.ua_string. But, will just removing user-agent logic here that affect other usages of EventLogging? Probably. 😉

@Sfaci wrote

Regarding the PHP implementation of EventLogging adding the user-agent details in any case, if we were capable of checking and knowing that the current stream if configured to opt out the user-agent details, would that be enough to exclude it? Or are there any other usages where the related stream configuration is not relevant?
Before EventLogging adds those details we could check if the stream is configured with http.request_headers.user-agent":false to skip adding them. Just wondering what you meant when you say "other usages", old instruments and their streams configured without that property? any others?

Just wondering what you meant when you say "other usages"

Any PHP submitted event that goes through that EventLogging code path. I'd expect them to be only legacy streams named like "eventlogging_*", but I am not certain!

Before EventLogging adds those details we could check if the stream is configured with http.request_headers.user-agent":false to skip adding them.

Technically, yes, but for reasons, that setting is an client specific eventgate setting. The full setting is producers.eventgate.enrich.enrich_fields_from_http_headers.... I'm not 100% sure making it eventgate specific was the right decision, but I think it was, since it is really producer client implementation specific.

The 'right' thing to do would be to add an e.g. producers.eventlogging.enrich_fields_from_http_headers and/or whatever specific settings to configure EventLogging producer client to do things.

FWIW, we do want to T303602: Generate $wgEventLoggingStreamNames from $wgEventStreams Specifically, see: T303602#7773661, which is similar to what I'm suggesting here: use EventStreamConfig to configure EventLogging producer client.

But, that is all quite annoying. Perhaps, a simpler solution would be to do some hackiness in EventLogging PHP. Assuming that only legacy eventlogging PHP streams need http.request_header:

In EventBusEventSubmitter

if ($streamName  starts with "eventlogging_") {
   set user-agent
}

I'm really not sure if that will cover the "other usages" or not though. The right thing to do is explicitly configure this behavior ¯\_(ツ)_/¯

Tagging this with Test Kitchen as it affects MP PHP library usage, and partly because I want to make sure this bug doesn't get lost.

Thank you @nettrom_WMF ! My faul! I added Metrics-Platform tag but I forgot the one you have added

@JVanderhoop-WMF can you help us understand DE impact?

I don't think there is any DE impact, except perhaps we can advise on solution and review changes. Code changes are entirely in EventLogging MW extension which is owned by TestKitchen(?) team.