This should only involve changing https://github.com/wikimedia/mediawiki-extensions-WikimediaEvents/blob/db66eac96fb29beffd89cc40edda1aae99eaee0e/modules/all/ext.wikimediaEvents.readingDepth.js#L21 from dependencies = [ 'schema.' + SCHEMA_NAME ], to dependencies = [],.

Should be straight forward but we recognise this is a slight context switch by people not familiar with this code.

In T214444#4905420, @phuedx wrote:

This should only involve changing https://github.com/wikimedia/mediawiki-extensions-WikimediaEvents/blob/db66eac96fb29beffd89cc40edda1aae99eaee0e/modules/all/ext.wikimediaEvents.readingDepth.js#L21 from dependencies = [ 'schema.' + SCHEMA_NAME ], to dependencies = [],.

The dependencies variable is used to track which additional RL modules that need to be loaded before any ReadingDepth logging can take place. We used this pattern (an RL "init" module that loads dynamic dependencies) because we wanted to avoid:

1. Loading the schema.ReadingDepth RL module unconditionally when ReadingDepth logging is enabled on 1% (or fewer) of pageviews; and
2. A race condition between the ReadingDepth logging and some experiments that run on MFE/MN.

Since the schema.* modules are no longer required to be loaded before EventLogging events can be logged, we no longer need to load the schema.ReadingDepth module. However, we still need to use this pattern to avoid #2 above.

Change 489710 had a related patch set uploaded (by Jdrewniak; owner: Jdrewniak):
[mediawiki/extensions/WikimediaEvents@master] Remove deprecated 'schema.ReadingDepth' module.

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

Change 489710 merged by jenkins-bot:
[mediawiki/extensions/WikimediaEvents@master] Remove deprecated 'schema.ReadingDepth' module.

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

@Jdlrobson I just want to be sure of the following:

1. Are you expecting an HTTP 204 status in the last QA step for the requests that appear after filtering?
2. Would be good (possibly redundant) to verify that ReadingDepth doesn't appear as a warning in the console?

Thanks!

In T214444#4946376, @Edtadros wrote:

1. Are you expecting an HTTP 204 status in the last QA step for the requests that appear after filtering?

Yes. In this case, the server MUST respond with 204 No Content.

I understand this shouldn't have any impact on the logged events and their data (except maybe as consequence of the performance improvement in general), but please flag it in case that assumption turns out to be wrong.

Test Result

Status: ✅ PASS
OS: macOS Mojave
Browser: Chrome DevTools Device Emulator (iPhone X)

Test Artifact(s):

The following message does not appear in the Console:

This page is using the deprecated ResourceLoader module "schema.ReadingDepth".

When filtered for ReadingDepth only two items appear with a 204 status.

In T214444#4949168, @Tbayer wrote:

I understand this shouldn't have any impact on the logged events and their data (except maybe as consequence of the performance improvement in general), but please flag it in case that assumption turns out to be wrong.

For the record: We also talked about this briefly in standup earlier today and determined that this task indeed doesn't need data signoff / data quality vetting. (If we already had the planned dashboard tracking average or median ReadingDepth values, it would have been worth taking a quick look there to see if those changed around the deploy date, but that is still being worked on in T209598.)