Not putting in the sprint quite yet, it's worth discussion and investigation first.

It doesn't look like we can detect the failed request. EventLogging is hardcoded to use asynchronous sendBeacon, which returns no success or failure information. The only alternatives coming to mind are,

• Directly make a null test post to EventLogging when setting up a survey, and store whether the request is successful. Or,
• Write a synchronous interface method for EventLogging, for when we don't need to navigate away during the call and can act on the response status.

Hm, I dug in a little bit and see that sendBeacon might return "false" for adblock exceptions, at least really exceptional ones: https://bugzilla.mozilla.org/show_bug.cgi?id=1234813

I'm ok with the null test post, it would allow us to turn off the client early and prevent unnecessary work. The sync method would work but I'd rather not go that route. It seems like if it's available everyone would use it and defeat the purpose of the queue and other things. So let's test and see if ad block makes sendBeacon return false, in which case we can easily just update the client code to react. And if not, I vote for your first idea.

I had another thought, documented in T280033: Investigate API endpoint for responding to QuickSurveys: that we return survey results through an API endpoint rather than eventlogging. We would probably still lose impressions in this case, so would still want to find a clever and non-invasive way to determine that the client did not send an impression.

So I'm not sure if you're talking about other problems but I hear two:

1. async production of events isn't good enough
2. adblock blocks event production

For 1, I thought that's why Andrew built the "guaranteed" version of EventGate production (https://wikitech.wikimedia.org/wiki/Event_Platform/EventGate#Producer_types:_Guaranteed_and_Hasty).
For 2, your idea makes sense, but I wonder if we could customize EventGate to have other endpoints that aren't blocked?

In T256463#7069491, @Milimetric wrote:

1. async production of events isn't good enough, [...] that's why Andrew built the "guaranteed" version of EventGate production (https://wikitech.wikimedia.org/wiki/Event_Platform/EventGate#Producer_types:_Guaranteed_and_Hasty).

That's exactly the mechanism I was looking for, thank you! I can find the handling code in the eventgate server implementation, but it seems there's no way to send a "guaranteed" event from the eventlogging client yet? Would it make sense to expose this in the client API, or does that belong in a new / different client implementation? In other words, should "Event Logging" always be sent hastily, and we introduce a new abstraction for sending to the same endpoint but synchronously?

2. adblock blocks event production, [... could we] customize EventGate to have other endpoints that aren't blocked?

It feels a bit like we would be inviting an "arms race". We should decide on a clear boundary between good-faith tracking events, and data consensually sent by the user. Background events are definitely the former, submitting a form is definitely the latter. Is there a use case in-between?

I can find the handling code in the eventgate server implementation, but it seems there's no way to send a "guaranteed" event from the eventlogging client yet? Would it make sense to expose this in the client API, or does that belong in a new / different client implementation? In other words, should "Event Logging" always be sent hastily, and we introduce a new abstraction for sending to the same endpoint but synchronously?

Yeah, I think that was always in the plan, @jlinehan / @Ottomata? I support a second way to send events, leaving "hasty" as the default.

2. adblock blocks event production, [... could we] customize EventGate to have other endpoints that aren't blocked?

It feels a bit like we would be inviting an "arms race". We should decide on a clear boundary between good-faith tracking events, and data consensually sent by the user. Background events are definitely the former, submitting a form is definitely the latter. Is there a use case in-between?

Yeah, that's probably right, a clear boundary would be better than trying to "sneak by", since that's not our intention anyway. I think opinions on the gray area in-between vary, some folks think some of the background tracking is necessary for basic site health, and has very little information about specific user agents.

1. Yeah ask @jlinehan I think.

2. See T263049: Avoid extra HTTPS connections for most Event Platform beacons

The fundamental problem here is that we're using an instrumentation pipeline for a production feature. Quick Surveys should be built on a data pipeline that's maintained by a team in Product. This is very relevant to our ongoing Shared Data Platform conversations.

I agree with Milimetric's summary. In my opinion, the instrumentation can stay, but without sending the entire response back in eventlogging. Instead, the response would be returned via an API, and saved to a new database table. Administrators could then query the results directly in an on-wiki interface.

Instead, the response would be returned via an API, and saved to a new database table. Administrators could then query the results directly in an on-wiki interface.

And/or it would be okay to use an event based API for this, and source the events into any interface for serving results. See T302925: [SPIKE] Investigate and Decide on Solution for Image Suggestions Feedback for an example of another project looking to do something like this.