For future reference, queries similar to the following could be useful for trying to identify legitimate server side errors.

Looking at same hour over multiple days for status code trends

select count(1), day, http_status from webrequest
where year = 2016
and (month = 6 or (month = 5 and day > 20))
and hour = 1
and normalized_host.project_class = 'wikipedia'
and access_method = 'desktop'
and uri_path rlike 'api.php$'
and uri_query rlike 'action=query&format=json&prop=info%7Cextracts%7Cpageimages%7Crevisions&formatversion=2&redirects=true&exintro=true&exchars=525&explaintext=true&piprop=thumbnail&pithumbsize=300&rvprop=timestamp&titles='
and uri_query rlike '&smaxage=300&maxage=300&uselang=content$'
group by day, http_status;

Looking for empty responses indicative of errors

select http_status, min(response_size), max(response_size), avg(response_size),
percentile(cast(response_size as BIGINT), 0.05),
percentile(cast(response_size as BIGINT), 0.5),
percentile(cast(response_size as BIGINT), 0.95)
 from webrequest
where year = 2016 and month = 6 and day = 4 and hour = 1
and normalized_host.project_class = 'wikipedia'
and access_method = 'desktop'
and uri_path rlike 'api.php$'
and uri_query rlike 'action=query&format=json&prop=info%7Cextracts%7Cpageimages%7Crevisions&formatversion=2&redirects=true&exintro=true&exchars=525&explaintext=true&piprop=thumbnail&pithumbsize=300&rvprop=timestamp&titles='
and uri_query rlike '&smaxage=300&maxage=300&uselang=content$'
group by http_status;

Change 297790 had a related patch set uploaded (by Bmansurov):
Do not log XHR cancellations

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

Change 297790 merged by jenkins-bot:
Do not log XHR cancellations

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

@phuedx is there something @Tbayer or I can do to test this live? like apending to the url popups=enabled&el=true? This would allow us to get a more familiar understanding of what is triggering what and why we might be seeing some #strange.

@JKatzWMF: You'll be able to test it live on Thursday, 14th but you should be able to test it on our staging server or on the Beta Cluster.

… Previously, if you hovered over one link and then immediately over another, then an "error" event would be logged as well as a "dwelledButAbandoned" event because the API client was aborting a request, which is typically treated as an error.

In T137059#2446636, @phuedx wrote:

… Previously, if you hovered over one link and then immediately over another, then an "error" event would be logged as well as a "dwelledButAbandoned" event because the API client was aborting a request, which is typically treated as an error.

Thanks for the explanation! That this can only happen in the test group (popups enabled) is consistent with the fact that currently almost all error events occur there.
However, the average number of events per link interaction is very close to 1 in the test group currently, so I'm left wondering if both of these events were being logged correctly.

@phuedx, when you say "previously" are you talking before this patch was introduced, or are you referring to the old adjacent links bug we fixed a while back?

@dr0ptp4kt: Before the change was merged.

Thanks, @phuedx. I take to this to mean that in the past:

if (~250ms or more elapsed && a preview card had not yet rendered && user moused out) {

it sent an error event plus a dwelledbutAbandoned

}

Whereas now, it should
if (~250ms or more elapse && a preview card has not yet been rendered && user moused out) {

it will send only a dwelledButAbandoned event

}

Do I have that right? And was it specifically the case of mousing away from one link to another link? Or did it also occur for mousing away to non-link real estate?

@dr0ptp4kt: As I understand it, it happened whenever the user moused away from a link while the API request was still in flight, i.e. it should not depend on the user mousing away to another link.

I'm having difficulty following the above conversation. Can someone update the description/create a new sub task if this has not been completed as requested?

What can I help clarify @Jdlrobson?

@phuedx The acceptance criteria " Client induced XHR cancellations from Hovercards ON users do not result in action = error events." is verifiable by me. If there are follow ups needed with regards to dwelledButAbandoned they seem unrelated and we should open a new task.

That said you reopened this saying there's still clarification required. It would help to restate this clarification and who you need it from.

@Tbayer ^