T217469 had a patch deployed... Is the issue on this task fixed, also, maybe?

In T218617#5044948, @Nuria wrote:

FYI that this blocks some changes to improve refinement of data, cause until these schemas are changed they cannot be refined with the new code. Ping @AndyRussG

Columned my update.

In T159255#4985534, @DStrine wrote:

It might be good for fr-tech to know that this exists and have links to it. However it's kind of a Seddon task. Fr-tech engineers should not attempt this without him.

Just to note, additional developer setup required for the fundraising vagrant role (such as perhaps specific XDebug stuff) should also be documented.

Here are the unfinished drafts from a while ago.

In T215088#4947784, @Niedzielski wrote:

@AndyRussG, do you think it would be possible to check the headers in CentralNotice.hooks.php? When a banner header with a value of null is set, maybe we don't call $out->addModules( 'ext.centralNotice.startUp' );. This would disable the CentralNotice banner JavaScript from executing.

In T215711, @Jdlrobson wrote:

consider during the render process of a banner catching any errors and hitting a stats beacon with the banner name similar to this:
https://github.com/wikimedia/mediawiki-skins-MinervaNeue/blob/master/resources/skins.minerva.scripts/errorLogging.js

Basically we can catch any errors and increment a counter at wikimedia.event.BannerError.<skin>.<bannerName> to help us identify banners that have problems

Another issue: T215711: POTY banners are causing client side error during banner display on mobile AND desktop.

Following IRL discussion with @thcipriani, it seems there's a pretty easy solution! If the script that automatically generates release branches for extensions can be made to create branches based on wmf_deploy, rather than master, that would allow us to keep fine-grained control over how and when things are deployed, and at the same time let deployments use existing standard procedures. Any thoughts? Thanks in advance!!!!

T215086 just merged into CentralNotice master. It should go out with the train next week.

In T214773#4932729, @MarcoAurelio wrote:

In T214773#4932711, @MarcoAurelio wrote:

When I went to aa.wikibooks I guess it's not displaying to me because I got it displayed already at Meta?

Was my language there not being set in Afar. Displays okay to me.

I've refactored the javascript and created a test banner with it:

In T214773#4925314, @MarcoAurelio wrote:

This is happening on 3 days and I'd rather not run into script issues that makes the banner go wild. Please help. Thank you.

I just re-ran the query, and the results are the same, as expected.

In T187207#4902806, @Nuria wrote:

Ping here @AndyRussG and @phuedx @jlinehan so they now Eventlogging is been refactored such it can now be added in every page, it does not validate events client side like it used to but you can set up that validation in your development environment. We recommend any instrumenting code that is not using eventlogging and rather sending events directly to the becaon (virtual pageviews and some FR banners) to be changed so it is resilient to changes on the EL client that might be upcoming.

In T214330#4907303, @Ejegg wrote:

Did you intend to have a different field than uri_host in the OR clause looking for Special:BannerLoader? Lools like uri_host has to be exactly meta.wikimedia.org.

In T214410#4906690, @Jdlrobson wrote:

As Timo predicted, I am not seeing any impact on any other JS on mobile or desktop.

I've set up a test banner with a JS error on the beta cluster.

Just FYI, here's the task about the data discrepancy: T214600.

Here is the data from Hive for actual calls to Special:BannerLoader to load and inject the banner into the page. The Hive query used follows.

In T214410#4903343, @Jdlrobson wrote:

I was seeing broken JS for certain pages, but it's possible of course these were unrelated to the banner...

@Krinkle , thanks much for the great explanation!

In T214330#4900177, @AndyRussG wrote:

In T214330#4900084, @Jdlrobson wrote:

Hi! That campaign currently sets no banner going out to the mobile site. We have a quick (though slightly less reliable) way of querying the data, which shows that after the banner was removed, it was displayed no more than four times per hour. This could be due to JavaScript with the banner choices payload being cached longer than it should, somewhere outside our datacenters, so outside our control. I don't think that's enough to be the source of the errors you see? BTW at its peak, the banner wasn't being shown more often than 60 times per hour. See this Turnilo plot.

From IRC:

In T214330#4900084, @Jdlrobson wrote:

Thanks for taking care of the banner problem. Errors haven't quite resumed to normal levels, is there a possibility old banner code could be cached? Obviously this could be another error, so I will continue investigating today.

I've updated the mobile banner. I don't think it will cause errors now. I also added an alterImpressionData function to get correct data about whether or not the banner was displayed.

Pulled this onto deploy1001 in the staging dir for wmf.12. git status no longer shows new commits in extensions/CentralNotice. :)

In T213915#4885692, @Reedy wrote:

Shouldn’t need that. It’s already in the core branch as that’s tracking wmf_deploy...

In T213915#4885571, @Reedy wrote:

You just need to update the git sub module for CN on deploy1001 and sync it :)