Page MenuHomePhabricator

Newtalk status remains set even after viewing talk page
Open, LowPublic

Description

Author: d.keith.d

Description:
As the summary states, newtalk notifications do not go away even after a user views their talk page. This problem did not occur until upgrading from MW 1.21 to 1.22rc2.

-----BEGIN SPELUNKING-----
Looking at the user_newtalk table, the most recent entries seem to consistently have actual timestamps in the user_last_timestamp column, rather than earlier entries, which were either NULL or blank for that column.
It seems that the message will always display if that user's ID is present in the user_newtalk table, regardless of the value in user_last_timestamp. Manually altering the table's contents supports this.
Comparing code in includes/User.php for 1.21 and 1.22rc2, getNewMessageRevisionId() was added. getNewMessageRevisionId() only seems to be used in includes/OutputPage.php to set $vars['wgUserNewMsgRevisionId']. This was just a cursory glance at the codebase, and nothing immediately jumped out at me as the cause of the problem.
-----END SPELUNKING-----

To reproduce:

  1. User A writes a new message on User B's talk page.
  2. User B should now see the orange new messages notification on every page, even after checking their talk page (either manually or via the links provided in the notification).

To resolve the ugly way:

  1. Find user ID of affected user.
  2. Log into MySQL console.
  3. DELETE FROM tableprefix_user_newtalk WHERE user_id=<affected user ID>;

Current setup:
MediaWiki 1.22.0rc2
nginx 1.5.7
php-fpm 5.4.22
memcached 1.4.13
MariaDB 5.5.32
Gentoo Linux


Version: 1.22.0
Severity: minor

Details

Reference
bz57840

Event Timeline

bzimport raised the priority of this task from to Low.Nov 22 2014, 2:36 AM
bzimport set Reference to bz57840.
bzimport added a subscriber: Unknown Object (MLST).

I cannot reproduce this. dfc3e3df did touch that area of the codebase recently. However the described issue is certainly not happening to me (tested on 1.22.0rc3- i.e. whatever is in git as REL1_22 currently)

Just to make sure, you don't have any extensions enabled that would affect new talk notices (e.g. Echo)?

d.keith.d wrote:

Echo is not installed, and I don't believe any installed extensions would impact notifications.

Installed extensions: Abuse Filter, AntiSpoof, CategoryTree, CharInsert, CheckUser, Cite, CodeEditor, ConfirmEdit, CreateBox, Editcount, EmbedVideo, ExpandTemplates, Gadgets, Google Analytics Integration, Interwiki, LabeledSectionTransclusion, MobileFrontend, OggHandler, OpenSearchXml, PageNotice, ParserFunctions, Renameuser, Scribunto, SidebarDonateBox, SyntaxHighlight, TitleKey, ToggleDisplay2, TorBlock, User Merge and Delete, Variables, WikiEditor

I can manually add entries to the user_newtalk table, and they will receive the notification. It does not matter if I set a timestamp, or even what value the timestamp is. (I even tried "THE FUTURE", still happened) If someone's user_id is present in the table, they will receive notifications. Is something in the 1.22rc2 release reading/updating the newtalk information differently from the 1.21 release?

d.keith.d wrote:

Behavior persists in 1.22.0 release.

Is this still an issue for you?

In cases like these you should always try disabling all extensions and see if the issue persists

I could reproduce this with the MW version currently live on Wikipedia:

  1. Wait until you get a new message on your talk page.
  2. Look at mw.config.get( 'wgUserNewMsgRevisionId' ). This is and should be the respective ID.
  3. Visit your talk page.
  4. Look at mw.config.get( 'wgUserNewMsgRevisionId' ) again. Now it should be null, but actually it's still the same as in step 2.

Reloading the talk page, doesn't help either, it is sent as 304 Not Modified.
The only way to reset the notification is to clear the cache.
Notices by Echo are not affected, they go away as expected.