The parent task tracks a combined Analytics-Performance effort to standardise a lightweight means of logging events, based what we've previously done in CentralNotice, in apps, and more recently in Popups.
We found a way that is entirely backwards-compatible. However, after scanning the codebase I found this line in ReadingDepth.js that is blocking progress due to it using a property that is @private. Please migrate this code as soon as possible.
// .. var schema = mw.eventLog.schemas[ SCHEMA_NAME ].schema, // .. function isValidSampleGroup( schema, bucket ) { return schema.properties[ bucket ] && /_sample$/.test( bucket ); } // ..
This is not supported and should not have been used in production. The status quo for producing events is for the JavaScript code to contain all required logic to produce the event object. I'd recommend following the same approach here.
This was never a public interface. If such feature is commonly needed, it should be requested through the normal means. Perhaps we can accomodate it in some generic way as part of next year's plans as part of a non-lightweight schema model. Although given that the revision-number is already controlled by the JavaScript code, it might make more sense to require the two to stay together. Perhaps a build-tool can help to semi-automatically update the script, but we shouldn't want to load schemas from Meta-Wiki during production page views.
Developer notes
Validation already happens inside EventLogging via the private mw.eventLog.validate function. If validation fails errors will be captured and logged (where?).
We chatted about this and decided the validation is not useful and should be removed.
QA steps
Test on https://reading-web-staging.wmflabs.org/w/index.php?title=Pharmacovigilance&mobileaction=toggle_view_mobile#
Verify that both PageIssues and ReadingDepth events show on page load and that the ReadingDepth events contain
"page-issues-b_sample": true,