I've been noodling on proposing that @Stashbot and/or scap create annotations in Grafana. I think such annotations would've been useful here.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Apr 18 2019
Apr 17 2019
There's a spike in VirtualPageview events today (see https://grafana.wikimedia.org/d/000000018/eventlogging-schema?orgId=1&from=1555459200000&to=1555516800000&var-schema=VirtualPageView) which appears to correspond to today's updates to the cluster. Further confirmation?
From the SAL:
Apr 15 2019
In T382#5108028, @Milimetric wrote:Thanks @Tgr, that's a big pivot from what I was expecting, but hey, let's do it!
In T218627#5110077, @Edtadros wrote:In the likely event I'm doing it wrong, after I click on the hamburger menu, I right click on Random and open that in a new window. <snip />
Apr 12 2019
In T220627#5107552, @Isaac wrote:And when do events for QuickSurveyInitiation and QuickSurveysResponses trigger?
- We are supposed to get a QuickSurveyInitiation every time the extension shows someone a survey: https://github.com/wikimedia/mediawiki-extensions-QuickSurveys/blob/c40f824c79b4e98993dafe7416a60fd6ad9cce45/resources/ext.quicksurveys.views/QuickSurvey.js#L100
@ovasileva: This might benefit from some investigation on our side too.
Apr 10 2019
Do consider that this change might be useful for setting up automated browser tests targetting AMC mode available/unavailable, since the Node.js stack doesn't support a local LocalSettings.php file.
Apr 9 2019
Additional notes that I raised during today's Backlog Grooming meeting:
In T219841#5096041, @Jdlrobson wrote:cc analytics and RelEng as there's potential for a lot of traffic to EventLogging (I've seen 80k a minute) to the WebClientError schema
Apr 8 2019
Apr 5 2019
@Tgr: When can this work be scheduled?
One alternative would be to launch the child Chromium process using firejail, which we're confident (?) does this kind of management.
In T217724#5044953, @pmiazga wrote:@akosiaris - yes, there is some logic that tries to kill the browser instances if browser.close() promise doesn't succeed. Looks like this code requires some tuning, and most probably it should try to kill the browser instance after some time without waiting for promise resolution/failure.
@Tgr: We'd talked about the deployment of this code having stalled out. Does this need a security review or at least an OK from Security prior to being deployed?
Work out how to deal with the frustration of non-deduplication. The feedback we got from people who have used EventLogging is that having the stack traces allowed them to fix the common bugs, but the other ones were harder to track down. We have no idea of the spread of our errors - all of them could be different, or many of them could be duplicates. We should think about what queries we can use to de-duplicate errors (And work out how many people they impact) and how our stack trace can be structured to help facilitate that.
Add stack traces to WebClientError events. Right now we're not including them in the current implementation because of the URL length. These will be essential. See T202026 for more information.
After thinking about this a little, it'd be useful for extensions/skins to be able to register a module that'll act as an error handler. AIUI the Sentry extension will suffer from the same issue as there's no guarantee that it'll be executed before the things that it intends to monitor will.
Apr 4 2019
In T219212#5070027, @Tbayer wrote:Yes, great point! I'm still slightly wondering about compatibility/comparability though - is it correct to interpret the documentation as saying that in cases where the unload event fires correctly, it should coincide with the pagehide event (with terminated state)?
In T208980#5082522, @Jdlrobson wrote:Does this need QA/QA steps?
My inclination is #1, given the relatively well-known complexity of #2 and the unknown-but-presumably-vast complexity of #3.
Apr 3 2019
My understanding is that tags can't be looked up by their translated name so existing references to "mobile web edit" would have to stay. Is that correct? For example, I only see messages being looked up for display purposes in https://github.com/wikimedia/mediawiki/blob/master/includes/changetags/ChangeTags.php (see ChangeTags::tagDescription and ::tagLongDescription).
Maintenance of the Wikipedia portals is our responsibility. That being said, I don't believe we've had the discussion as to whether the portals are frozen. If not, then this work is no different from our other work (prioritisation and estimation and an eventual commitment).
Apr 2 2019
Ping @santhosh and @Jdrewniak.
Apr 1 2019
In T216063#5074754, @Milimetric wrote:We are leaning towards filtering out events coming from non-wikimedia domains.
Mar 28 2019
☝️ If necessary, we could break out migrating from using the unload event to using the pagehide event into another task.
In T208980#4954751, @nray wrote:In T208980#4954700, @phuedx wrote:@nray: See @Krinkle's detailed explanation here: T208980#4792762
Thank you, I didn't read that closely enough. Sounds like in addition to the unload event not firing in common scenarios on mobile devices the beforeunload event wouldn't fire either.
Background/motivation: A limitation of the current ReadingDepth data is that the pageUnloaded event may not be fired if the page is terminated by the browser/system before unload. On mobile, this actually happens in a majority of cases and biases our data especially when comparing reading times on desktop and mobile ( https://meta.wikimedia.org/wiki/Research_talk:Reading_time/Work_log/2018-11-02 ).
High because the debt is in an area that we're actively working on and it's both a UX problem and a resource consumption problem.
@Jdlrobson: T217814#5062730 doesn't have a lot of context (e.g. it may've been a comment written in haste during a meeting). Can you advise whether this task should be split up or reestimated?
I kicked off a build and it passed: https://integration.wikimedia.org/ci/view/Reading-Web/job/selenium-MinervaNeue/905/
Ping @ovasileva and @alexhollender for prioritization.
Growth-Team are marked as the stewards for MediaWiki-extensions-FlaggedRevs on https://www.mediawiki.org/wiki/Developers/Maintainers.
A data point (may or mayn't be related): SauceLabs had an incident yesterday: https://status.us-west-1.saucelabs.com/incidents/gywtsd27cq06
Mar 27 2019
How should this be QA'd? What are the steps that should be taken to prove that this works?
Mar 26 2019
Each item on the menu will be tracked in the same schema where main menu tracking occurs
Mar 22 2019
Mar 20 2019
Since all the subtasks are resolved, can this be resolved?
Mar 19 2019
If the code for QuickSurveys loads AFTER MobileFrontend, the hook will be registered too late and the survey will never show.
The task that led to the introduction of the mobile.betaoptin event: T111188
- Data for clicks to all new links can be collected using https://meta.wikimedia.org/wiki/Schema:MobileWebMainMenuClickTracking
@Jdlrobson: Would changing the message require that any existing workflows are updated or would folk still have to refer to the tag by its name when querying the DB or specifying it as an argument for the tagfilter parameter in an MW API call, for example? That is, would the tag look like it was called "mobile web action" but still actually be called "mobile web edit"?
Mar 18 2019
Mar 15 2019
As for on-wiki uses by the general public:
Mar 14 2019
Would replacing the textarea with a div if the page is protected work? This would be cleaner than manipulating the DOM in JS IMO.
In T217526#5024391, @Jhernandez wrote:@ovasileva This is probably a bug on mobile web too?
This appears to have been fixed in https://en.wikipedia.org/w/index.php?title=Calculus&type=revision&diff=887407355&oldid=886050145, which is the fix that @Tacsipacsi proposed in T217526#5012719.
Mar 13 2019
Mar 12 2019
Mar 8 2019
Mar 7 2019
@mforns: I'm pretty sure this is deployed and (re)started as there are log lines appearing in Kibana for the following query: https://logstash.wikimedia.org/goto/36329f5fd2348e181177ff879800d9c0
Mar 6 2019
In T217142#4997724, @Ottomata wrote:Unless we have a generic schema for client error logs! :) Might not be a bad idea.
Mar 5 2019
Mar 4 2019
Feb 28 2019
Also CCing @dr0ptp4kt
Feb 27 2019
CC @Jhernandez, @Tgr, @faidon, @fgiunchedi, @herron for visibility. My apologies in advance for the description churn, y'all.