Caused by a JS error: Cannot read property 'append' of undefined in mw.flow.ui.ReplyWidget.prototype.intializeEditor where it does this.$editorContainer.append(this.editor.$element); (this.$editorContainer is undefined)
...and it still failed.
Looking at the implementation of LoginNotifyPresentationModel::getHeaderMessage(), it looks like it can return an empty string in some cases.
If you're on a topic page associated with a user talk page, the sidebar should contain the "user contributions" link (and other user-relevant links) just as it does when you view the user talk page directly.
The query for this is:
SELECT /*! STRAIGHT_JOIN */ rc_id,rc_timestamp,rc_user,rc_user_text,rc_namespace,rc_title,rc_comment,rc_minor,rc_bot,rc_new,rc_cur_id,rc_this_oldid,rc_last_oldid,rc_type,rc_source, rc_patrolled,rc_ip,rc_old_len,rc_new_len,rc_deleted,rc_logid,rc_log_type,rc_log_action,rc_params,wl_user,wl_notificationtimestamp, (SELECT GROUP_CONCAT(ct_tag SEPARATOR ',') FROM `change_tag` WHERE ct_rc_id=rc_id ) AS `ts_tags`, ores_damaging_cls.oresc_probability AS `ores_damaging_score`,ores_goodfaith_cls.oresc_probability AS `ores_goodfaith_score`, fp_stable,fp_pending_since FROM `recentchanges` LEFT JOIN `watchlist` ON (wl_user = '22559448' AND (wl_title=rc_title) AND (wl_namespace=rc_namespace)) LEFT JOIN `ores_model` `ores_damaging_mdl` ON (ores_damaging_mdl.oresm_is_current = '1' AND ores_damaging_mdl.oresm_name = 'damaging') LEFT JOIN `ores_classification` `ores_damaging_cls` ON ((ores_damaging_cls.oresc_model = ores_damaging_mdl.oresm_id) AND (rc_this_oldid = ores_damaging_cls.oresc_rev) AND ores_damaging_cls.oresc_class = '1') LEFT JOIN `ores_model` `ores_goodfaith_mdl` ON (ores_goodfaith_mdl.oresm_is_current = '1' AND ores_goodfaith_mdl.oresm_name = 'goodfaith') LEFT JOIN `ores_classification` `ores_goodfaith_cls` ON ((ores_goodfaith_cls.oresc_model = ores_goodfaith_mdl.oresm_id) AND (rc_this_oldid = ores_goodfaith_cls.oresc_rev) AND ores_goodfaith_cls.oresc_class = '1') LEFT JOIN `flaggedpages` ON ((fp_page_id = rc_cur_id)) WHERE ((ores_damaging_cls.oresc_probability BETWEEN 0.879 AND 1)) AND ((ores_goodfaith_cls.oresc_probability BETWEEN 0.86 AND 1)) AND (rc_timestamp >= '20170418000000') AND rc_new IN ('0','1') ORDER BY rc_timestamp DESC LIMIT 50
Mon, Apr 24
About the exclude button: I think we should have a single "exclude" button for the entire namespace dropdown, not per namespace.
For some reason the bot did not report this: https://gerrit.wikimedia.org/r/#/c/349946 by @Tgr adds a maintenance script to clean up the old rows (or, technically, adds this functionality to an existing maintenance script).
Furthermore, @jmatazzoni reports that he (correctly) does not see the preference, but that it (incorrectly) behaves as if it's set to true. Hidden preferences should behave as if they are set to their defaults, and the default is false.
Sat, Apr 22
Fri, Apr 21
And a simulation of what it would look like with the current (long) text for the LoginNotify notification:
Without the RCFilters beta feature enabled, you'd see two separate filters, both "Hide patrolled edits" and "Hide reviewed edits". There is some overlap between those two. The simple thing to do here would be to just port "Hide reviewed edits" to a simple "Reviewed" / "Unreviewed" filter group (same as "Patrolled" / "Unpatrolled", which has already been ported), but we may want to consider if we should handle it differently because of the overlap that exists (it sounds to me like all reviewed edits are also patrolled, but some things can be patrolled without being reviewed?).
Thu, Apr 20
Here's what truncated vs untruncated would look like:
Most likely with the next deployment train (April 25-27), but only if the patch is fixed (because it doesn't seem to work right now) and merged before then.
Wed, Apr 19
The 90M rows of old data are known: T159753: Concerns about ores_classification table size on enwiki. I was going to clean them up, but haven't gotten around to doing that yet, and it's probably a good idea to wait until after the switchover is completely over (i.e. we're back in eqiad) before I do that.
@Whatamidoing-WMF Can you reproduce this in safe mode? https://en.wikipedia.org/wiki/Special:Notifications?safemode=1 will load the notifications page without any gadgets or user/site scripts. If you can reproduce in safe mode, then there's a bug in our software and we'll try to track it down; if not, then the issue is with a user/site script or gadget.
Update: I've introduced a new feature that lets you test with gadgets and user scripts disabled by going to https://cs.wikipedia.org/wiki/Special:Notifications?safemode=1 . Please test this in safe mode and see if you can reproduce the bug. If you cannot reproduce in safe mode, the cause must be a gadget or user script.
Tue, Apr 18
As far as I can tell, all cases of un-unserializable events are due to very old Flow events. Prior to rEFLWe5f75381274a: Serialize UUID into something more compact / T64532: Flow: serialize UUID objects as strings, the UUID class in Flow included an MWTimestamp object in its serialization, which in turn contains a DateTime object. This DateTime sometimes has its timezone set to +00:00, which causes an exception in HHVM but not in Zend(!). It took me a while to figure this out because of T146285: Switch mwscript from Zend PHP5 to default php alternative (egHHVM), which meant that unserializing the bad data failed in production but worked in mwscript eval.php. I noticed that it did fail on real app servers, and went down a version discrepancy rabbit hole, but it turns out that that was a red herring caused by my workaround for mwscript being unavailable on those machines, which ended up using HHVM (php) instead of Zend (php5).
This seems to be partially expected. T158176: Build / migrate to HHVM 3.18 says "3.18.2 is running on the mediawiki canaries, but the wider rollout is held back until after the DC switchover", which seems sensible.
So it looks like arz, bqi and luz do end in $3 (modulo RLE characters maybe)? And lrc and mzn don't have $3 at all, which seems like a bug. The only language where it would really make a difference is avk, and looking at that message I'm not sure if the translators understood what they were doing there. So your suggestion of removing $3 and adding the links separately sounds good to me.
This was almost certainly fixed by rMWe4d6238c0046: Language::truncate(): don't chop up multibyte characters when input contains… about 18 months ago. Please reopen if this still happens.
GMail now does display our notification icons. We did have to use PNGs instead of SVGs to make that happen, but we did that a while ago.
This was resolved long ago: bundles open when clicked and do not have a primary link.
We decided to stay with timestamp-based seen-ness, and made some improvements (including a global timestamp) to make it work better.
We decided not to do this.
This seems fixed to me. Please reopen if slow query log entries reappear.
Mon, Apr 17
The fix should be deployed now; it didn't quite work the first time because of T163158: acpi_pad consuming 100% CPU on tin, so I had to deploy it again after that was fixed.
I was granted permission to deploy the fix, and tried to deploy it, but because of issues with the deployment server the deployment didn't fully work, and the fix is now half-deployed. I'm trying to get someone to fix that server so I can deploy it properly.
Apparently this previously happened on tin's sister host mira as well: T137647#2791091
tin is also affected, its kernel version appears to be 4.4.0-3-amd64 .
We've already written and merged https://gerrit.wikimedia.org/r/348504 which disables the ?fromrc=1 addition, and we won't add it back unless and until we find a way to make it non-disruptive.
I had not thought about link visitedness at all when implementing this. My apologies for the disruption! (And for missing the first comment about it.)
This is the behavior @jmatazzoni asked for, I'll leave it to him to defend it.
This is the same on wikitext talk pages, right? If you delete a "topic" (section), the name of that section will still be visible in the history, in the diffs of those edits and usually in their edit summaries too. If there is defamatory or otherwise terrible content in these section names, an oversighter can suppress the relevant edits. This is also possible in Flow, where an oversighter can suppress topics with defamatory content in their titles.