(Photography by Niek Hidding.)
A few quick thoughts:
In today's FSG I brought up this pending decision and stated that either eslintrc/eslintignore or package.json would be positive step forward.
@tstarling Yeah, the main thing I was thinking about with corruption is things we put outside the main transaction that we still all expect to happen but don't have a retry or other eventual consistency mechanism for. In other words, deferred updates. They each get their own transaction.
PHP Notice: Undefined index: 1
Appears resolved. Or was there more? Feel free to re-open if so :)
Looking at the code, I see the following:
Sounds good to me.
Hi, I'd like to expand some of the local wiki context, their use case as I understood it.
Tue, Dec 11
I don't have a preference for whether to remove or keep the sql command on mwdebug/canary servers. However, looking at the above patch, I notice something else:
I've also updated my WIP at https://gerrit.wikimedia.org/r/#/c/performance/arc-lamp/+/447555/, but no need to focus on that until we pick that up for T200108 and swift storing etc.
For the record, the upstream for this library is https://crisp.tweakblogs.net/blog/cat/716. We've successfully upstreamed patches before, although not since 2012. And it looks like it certainly isn't actively maintained, but if and when this is patched, we should at least send the author a note in case they're still looking after it for the benefit of other users.
Tagging Editing-team and CC-ing Tim and Anomie, per mw:Maintainers for Scribunto.
Not seen in WMF Logstash for at least 30 days.
Mon, Dec 10
See also https://chrome.google.com/webstore/detail/pherrit/polcefipbgcdfkpbmmbdjgkgfgjoebij, which provides this in an even nicer way (on workboard views).
At https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/ElectronPdfService/+/473485/, verification was bypassed for this reason.
I'd support the proposed outcome by @Anomie of capturing the IDs of wikis for which the script produced errors (not the errors themselves).
Removing the T110022 sub-task because creation a the library isn't blocked on having our HTTP abstraction published. Nothing in the relevant interfaces and utilities here uses HTTP functions. There's merely one BagOStuff implementation that MediaWiki has (RESTBagOStuff) that uses HTTP, which doesn't need to be in the library (and for many years, wasn't in core, either).
I often audit mobile/desktop pages and analyse the critical path between the start of the HTML and the first bit of JS execution that is "meaningful" to users. These variables appear early on as low-hanging fruit for removal, to reach that point of execution earlier.
@Alexia Apologies for the inconvenience resulting from this.
@ema @BBlack This outcome of this task should be for the mtail/varnishrls metric collector to only apply to traffic for hosts where ResourceLoader is available, so as to stop the data pollution from unrelated requests for hosts where there is not meant to be an /w/load.php entry point.
Sun, Dec 9
Un-assigning for now as this isn't current quarter's goal. Current quarter has T202154 as my optimisation theme.
@BPirkle That might be a problem. It is already a source of uncertainty to me whether our execution timeout honours things like finally and deferred updates. I've not yet found evidence that it causes corrupt state due to unexpected exists, though, in part because we use a transaction for all writes which means an early exist just effectively rolls it back. In theory this can still cause problems with secondary writes outside that transaction to other DBs, file backends, and caches; but our convention is to perform those writes after the transaction commits via db-idle callbacks.
@Tgr That seems fine by me as a first step (separate channel).
- performance (generated from where?)
Other industry examples: