We might start with a simpler solution, just warning on beforeunload.

I was surprised to not find any metrics for this under "recoverable errors". Maybe tracking is the next step?

We think we currently show the template name. This should be discussed, maybe we want to remove it.

I added a negative, that multiple extensions cannot use the same schema even when at the same revision level.

This is probably much easier than we had estimated, and I can reuse much of what I just did for T231529: Understand current referencing behavior as baseline for ReferencePreviews, so I'm pulling into the sprint.

In T109939#3724744, @Tgr wrote:

[...] the gerrit admin page and the Phabricator repo page both utterly suck as a landing page.

In T233591#5515270, @elukey wrote:

We started collecting python2 -> python 3 use cases in https://phabricator.wikimedia.org/T204734, and there is a subtask about eventlogging: T233231

This works in some cases, but exceptions where we fail to report the error are tracked in T233576: Source wiki edit logic doesn't detect some failure cases.

No reason to rush this. I can't actually verify yet, none of these messages appear in beta logstash, which is strange since I ran an import an hour ago.

I'll try a naive implementation in Cite.

Here's a draft schema which should cover our needs for both the baseline and ReferencePreviews metrics:
https://meta.wikimedia.org/wiki/Schema:ReferencePreviews

EventLogging doesn't support a guaranteed-beacon mode, i.e. browsers without beacon support will execute <img> fallback logic which does block the page unload when clicking on an outbound link. I would prefer to skip non-beacon browsers, we should discuss as a team.

We should be able to unblock this work within the next month, as soon as we decide what to record for T214493 and T231529.

There's a place in Schema:Popups for "reference" events, but it's unused, here's a breakdown of actual values:

select event_previewType, count(*) from Popups_16364296 group by event_previewType;
+-------------------+-----------+
| event_previewType | count(*)  |
+-------------------+-----------+
| NULL              | 291380619 |
| generic           |     60583 |
| page              |  19836700 |
+-------------------+-----------+

Thiemo found this relevant deprecation task for the Popups instrumentation: T193051: Remove all page previews instrumentation code

Okay, I see this in code review:

It might be that we want to drop this again later, if it turns out this creates more issues than it solves. I think the chance for this to happen is rare, and the benefits are worth the risk. Let's do it.

In T227849#5505651, @thiemowmde wrote:

I'm just not sure if not importing tags was a deliberate decision back then?

In T231529#5499042, @awight wrote:

Since tracking outbound links will slow down the user's navigation, especially sample there. We have to wait until our metrics callback completes.

Eh I guess this is still "doing" until the graph is ready. We'll need to wait for next week's train before data will be available.

The patch is verified working on the beta cluster, so now we just have to create the Grafana panel, once data is available.

I think the last step is to deploy? I'll leave it up to @thiemowmde whether we should backport or let this go out with next Wednesday night's train.

In T228851#5502670, @Stashbot wrote:

Mentioned in SAL (#wikimedia-operations) [2019-09-18T11:25:52Z] <awight@deploy1001> Synchronized wmf-config/CommonSettings.php: SWAT: [[gerrit:537586|Enable FileImport source wiki editing (T228851)]] (duration: 01m 03s)

Monitoring

• Spot-check recent imports, following link to the original files, https://commons.wikimedia.org/wiki/Special:RecentChanges?hidebots=1&translations=filter&hidecategorization=1&hideWikibase=1&tagfilter=fileimporter&limit=100&days=7&urlversion=2
• Watch Grafana panels for source wiki edit and delete failures, any number more than zero is cause for concern.