[Bug 37225] Several history entries for the same content and watchlists showing wrong article size changes
https://bugzilla.wikimedia.org/show_bug.cgi?id=37225 --- Comment #69 from Daniel Kinzler 2012-08-27 13:17:20 UTC --- Possibly related (may cause premature commits, though I don't see how it could trigger this exact problem): I80faf2ed To avoid the issue of premature commits and general transaction confusion, I suggest to merge I8c0426e1 soon (along with the fixes I mentioned in the comments there). -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 37225] Several history entries for the same content and watchlists showing wrong article size changes
https://bugzilla.wikimedia.org/show_bug.cgi?id=37225 --- Comment #68 from Jarry1250 2012-07-23 08:50:05 UTC --- Did we apply a fix retrospectively in the end? -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 37225] Several history entries for the same content and watchlists showing wrong article size changes
https://bugzilla.wikimedia.org/show_bug.cgi?id=37225 Aaron Schulz changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 37225] Several history entries for the same content and watchlists showing wrong article size changes
https://bugzilla.wikimedia.org/show_bug.cgi?id=37225 --- Comment #67 from Aaron Schulz 2012-07-21 18:42:44 UTC --- I've fixed DATA_FOR_UPDATE loading in https://gerrit.wikimedia.org/r/#/c/16228/. I've replaced the 'forupdate' loading with 'fromdbmaster' in EditPage in https://gerrit.wikimedia.org/r/#/c/16229/. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 37225] Several history entries for the same content and watchlists showing wrong article size changes
https://bugzilla.wikimedia.org/show_bug.cgi?id=37225 --- Comment #66 from Platonides 2012-07-12 07:31:26 UTC --- That's the exception added by Aaron. It's better to throw such exception than producing this bug. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 37225] Several history entries for the same content and watchlists showing wrong article size changes
https://bugzilla.wikimedia.org/show_bug.cgi?id=37225 --- Comment #65 from Liangent 2012-07-12 05:28:59 UTC --- It seems the isolation between different edits or actions which creates revision has been removed, and this introduces another (maybe more severe) bug: if two such requests are sent simultaneously, request B may fail with "" and 21906884 is the revid of another edit by request A, which is incomplete when request B is processed. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 37225] Several history entries for the same content and watchlists showing wrong article size changes
https://bugzilla.wikimedia.org/show_bug.cgi?id=37225 --- Comment #64 from Alexandre Emsenhuber [IAlex] 2012-07-11 18:35:09 UTC --- So first my apologies to have caused this bug with Gerrit changeset #6079. I did already mentioned MySQL's "consistent read" feature there, but I did not see that problem. I did choose to use "FOR UPDATE" in EditPage.php to catch edit conflicts before executing WikiPage::doEdit(), but it seems that this is causing more harm than good. An easy solution is to remove the "FOR UPDATE" and use the already-present conflict detection code in WikiPage::updateRevisionOn(), since it put a condition on the page_latest field with fetched value when updating the database row. So a value mismatch will trigger a transaction rollback and an edit-conflict form. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 37225] Several history entries for the same content and watchlists showing wrong article size changes
https://bugzilla.wikimedia.org/show_bug.cgi?id=37225 --- Comment #63 from christ...@quelltextlich.at 2012-07-11 17:53:28 UTC --- Seems Aaron provided a hotfix while I prepared the logs for uploading in the previous comments :D But towards his order of a "more ideal solution" ... it seems the culprit is the usage of "FOR UPDATE" in (only) some of the relevant queries. So some queries see values updated by other transactions, while other queries do not. Assume we want to edit a page PageZ that is at revision 5. Both B and C are each about to submit a new revision. B submits first, and opens a master (say BM) and a slave (say BS) connection to the database. Both connections are on a transaction. For both BM and BS, the page's page_latest is obviously 5, and the highest rev_id in the revision table for the page is obviously 5 as well. /Before/ B's loadPageData executes the sql of EditPage.php:1206 $this->mArticle->loadPageData( 'forupdate' ); C starts submitting her revision. So C also opens a master (say CM) and a slave (say CS) connection to the database. Both connections are on a transaction as well. For both CM and CS, the page's page_latest is obviously 5, and the highest rev_id in the revision table for the page is obviously 5 as well. Now while B's request is handled slowly, C's request zooms right through. C's revision gets added (using rev_id 6) on CM for the page. For BM, BS, and CS, the pages page_latest is still 5, while for CM it is 6. Accordingly for the page's highest rev_id. C's request is done. The transactions CM and CS are committed. Now B's request reaches the SQL for EditPage.php:1206 $this->mArticle->loadPageData( 'forupdate' ); . This SQL statement (for connection BM) is SELECT /* WikiPage::pageData Root */ page_id,page_namespace,page_title,page_restrictions,page_counter, page_is_redirect,page_is_new,page_random,page_touched,page_latest,page_len FROM `page` WHERE page_namespace = '0' AND page_title = 'PageZ' LIMIT 1 FOR UPDATE Although the page's page_latest has been 5 before for BM, this query now yields a page_latest of 6, due to the "FOR UPDATE" suffix. But recall that for both BM and BS the page's page_latest is still 5 without "FOR UPDATE", just as their highest rev_id in the revision table for the page is also still at 5. So the subsequent Revision::fetchFromConds on BS (with "rev_id = '6'") fails. Also the subsequent Revision::fetchFromConds on BM (with "rev_id ='6'") fails. Should we: - just stick with the hotfix of exception throwing, - restart our transaction to be able to fetch revs that have been committed after our transaction started, - add more "FOR UPDATE"s to be able to fetch revs that have been committed after our transaction started, - get rid of the "FOR UPDATE"s and detect an edit conflict, or - something completely different? -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 37225] Several history entries for the same content and watchlists showing wrong article size changes
https://bugzilla.wikimedia.org/show_bug.cgi?id=37225 --- Comment #62 from Aaron Schulz 2012-07-10 00:03:16 UTC --- Note that an exception is now thrown per comment 56. This should not be occurring anymore. A more ideal solution is still in order. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 37225] Several history entries for the same content and watchlists showing wrong article size changes
https://bugzilla.wikimedia.org/show_bug.cgi?id=37225 --- Comment #61 from christ...@quelltextlich.at 2012-07-09 23:54:07 UTC --- Created attachment 10836 --> https://bugzilla.wikimedia.org/attachment.cgi?id=10836 SQL logs taken, while the bug occurs -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 37225] Several history entries for the same content and watchlists showing wrong article size changes
https://bugzilla.wikimedia.org/show_bug.cgi?id=37225 christ...@quelltextlich.at changed: What|Removed |Added CC||christ...@quelltextlich.at --- Comment #59 from Aaron Schulz 2012-07-09 17:13:26 UTC --- (In reply to comment #58) > What happens when the master can't be reached (in Revision::newFromConds())? > Any chance we could get a null back instead of an exception? Normally, no unless the ignoreErrors() function was called on the DB. Running the sha1 script though, I noticed that sometimes the DB class forgets that the connection was dropped, and I get raw mysql_query warnings. I think this happens when DB errors are caught and then the DB is used further down the line. --- Comment #60 from christ...@quelltextlich.at 2012-07-09 23:51:48 UTC --- After some playing around with xmldumps-test, I am able to reliably reproduce the problem automatically: It's a race condition, that can be triggered in the following way: (1) Start with a page, whose last revision is from PersonA. (2) PersonB starts uploading a new revision of the page. (3) PersonC starts uploading a new revision of the page. (4) Request from PersonC finishes (5) Request from PersonB finishes Between (2) and (5), PersonB's connection to the master database executes the SQL sequence [...] SELECT /* User::loadGroups */ ug_group FROM `user_groups` WHERE ug_user = '1' SELECT /* Block::newLoad Root */ ipb_id,ipb_address,ipb_by,ipb_by_text,ipb_reason,ipb_timestamp,ipb_auto,ipb_anon_only,ipb_create_account,ipb_enable_autoblock,ipb_expiry,ipb_deleted,ipb_block_email,ipb_allow_usertalk,ipb_parent_block_id FROM `ipblocks` WHERE ipb_address = 'Root' SELECT /* WikiPage::pageData Root */ page_id,page_namespace,page_title,page_restrictions,page_counter,page_is_redirect,page_is_new,page_random,page_touched,page_latest,page_len FROM `page` WHERE page_namespace = '0' AND page_title = 'PageZ' LIMIT 1 FOR UPDATE [...] If PersonC's request is dealt /between/ this given first and third SELECT, both revisions (PersonB's and PersonC's) end up in the database: The oldest version is PersonA's, followed by PersonC's, and finally PersonB's. In the "Recent Changes", the PersonB's revision lists its full size as +value. No database error, connection loss, network problem, etc need to occur. Yes, it's only a rough description. But as I will not find time to investigate the issue further in the next few days, I hope this description and SQL sequence nevertheless helps others to quickly reproduce the race condition as well and hunt it down. As the setup is tedious, I attached some log files. ;-) -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 37225] Several history entries for the same content and watchlists showing wrong article size changes
https://bugzilla.wikimedia.org/show_bug.cgi?id=37225 Ariel T. Glenn changed: What|Removed |Added CC||ar...@wikimedia.org --- Comment #58 from Ariel T. Glenn 2012-07-09 08:16:09 UTC --- What happens when the master can't be reached (in Revision::newFromConds())? Any chance we could get a null back instead of an exception? -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 37225] Several history entries for the same content and watchlists showing wrong article size changes
https://bugzilla.wikimedia.org/show_bug.cgi?id=37225 --- Comment #57 from Liangent 2012-07-07 05:48:01 UTC --- (In reply to comment #56) > I did some more live debug logging. > But why is doEdit() called more than once? per previous comments, this also happens to bot edits. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 37225] Several history entries for the same content and watchlists showing wrong article size changes
https://bugzilla.wikimedia.org/show_bug.cgi?id=37225 --- Comment #56 from Aaron Schulz 2012-07-06 22:19:17 UTC --- I did some more live debug logging. I see things like: 2012-07-06 22:05:50 mw69 frwiki: Could not load rev 80557024 for Bargen (Berne) [208044]. 2012-07-06 22:02:57 mw68 itwiki: Could not load rev 50844198 for Grandecourt [195339]. 2012-07-06 21:28:18 mw39 enwiki: Could not load last rev for Dallas Mavericks [72880]. ...which usually refer to duplicate edits. So the "$revision = Revision::newFromPageId( $this->getId(), $latest );" call in loadLastEdit() seems to return false sometimes, causing getRawText() to return false, causing the strcmp( $text, $oldtext ) to detect a change in text. This can lead to duplicate revision, and an RC row with a change size of the whole text (since $oldsize is 0). I don't know why that happens, or why newFromPageId() would return false there. It falls back the master if the revision is not found, so in theory it shouldn't be slave lag. But looking at the above logs (which give rev ID, page title, and page ID) and inspecting the pages, those revs clearly exist with those parameters, so there is no reason they shouldn't have been found. Normally, something like this points to a bug around slave lag. In any case, I may be able to stop this problem by just throwing exceptions when getRawText() returns false but getLatest() is not zero. I also see strange things like: 2012-07-06 21:49:15 srv216 enwiki: Could not find text with ID 0. ...that sounds like its own bug to look at. Sounds like something maybe using Revision::newFromRow() without rev_text_id in the field list and then calling getText(). -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 37225] Several history entries for the same content and watchlists showing wrong article size changes
https://bugzilla.wikimedia.org/show_bug.cgi?id=37225 --- Comment #55 from lex ein 2012-07-01 06:06:27 UTC --- (In reply to comment #54) > ... the title of this bug is misleading ... I see the title was nicely expanded. Thx. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 37225] Several history entries for the same content and watchlists showing wrong article size changes
https://bugzilla.wikimedia.org/show_bug.cgi?id=37225 Platonides changed: What|Removed |Added Summary|Several history entries for |Several history entries for |the same content|the same content and ||watchlists showing wrong ||article size changes -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
