Last modified: 2014-01-08 19:54:27 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T61197, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 59197 - Flow: page fails to load "InvalidDataException( 'Missing Posts:...)"
Flow: page fails to load "InvalidDataException( 'Missing Posts:...)"
Status: RESOLVED FIXED
Product: MediaWiki extensions
Classification: Unclassified
Flow (Other open bugs)
master
All All
: Unprioritized major (vote)
: ---
Assigned To: Nobody - You can work on this!
http://ee-flow.wmflabs.org/wiki/Talk:...
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2014-01-02 00:10 UTC by spage
Modified: 2014-01-08 19:54 UTC (History)
5 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description spage 2014-01-02 00:10:53 UTC
On ee-flow, Talk:Sandbox shows just
  Error
  Failed to load the requested data. 

The exception (below) is
  Missing Posts: {"2":"050d40cb239ff00fc8b1fa163e68c4ac"}
I had earlier failures trying to add reply posts to this page, possibly because ee-flow didn't have the workflow_user_ip SQL patch. Maybe those failures left ee-flow in an inconsistent state.

I am able to view an individual topic from Talk:Sandbox that I had permalinked
http://ee-flow.wmflabs.org/w/index.php?title=Talk:Sandbox&workflow=050b9f659413f00fc8b1fa163e68c4ac (though there's some kind of username display glitch there).
This suggests that Flow code needs to be more robust when loading a board. A missing post should appear as, e.g. a pink errorbox
   [Missing post 050d40cb239ff00fc8b1fa163e68c4ac]

FWIW the code has a comment
      // TODO: fake up a pseudo-post to hold the children? At this point in
      // dev its probably a bug we want to see.

debug.log contains

[exception] [6ba067b4] /wiki/Talk:Sandbox   Exception from line 102 of /srv/mediawiki/extensions/Flow/includes/Data/RootPostLoader.php: Missing Posts: {"2":"050d40cb239ff00fc8b1fa163e68c4ac"}
#0 /srv/mediawiki/extensions/Flow/includes/Block/TopicList.php(248): Flow\Data\RootPostLoader->getMulti(Array)
#1 /srv/mediawiki/extensions/Flow/includes/Block/TopicList.php(144): Flow\Block\TopicListBlock->getTopics(Object(Flow\Data\PagerPage))
#2 /srv/mediawiki/extensions/Flow/includes/View.php(72): Flow\Block\TopicListBlock->render(Object(Flow\Templating), Array)
#3 /srv/mediawiki/extensions/Flow/Hooks.php(151): Flow\View->show(Object(Flow\WorkflowLoader), 'view')
#4 [internal function]: FlowHooks::onPerformAction(Object(OutputPage), Object(Article), Object(Title), Object(User), Object(WebRequest), Object(MediaWiki))
#5 /srv/mediawiki/includes/Hooks.php(199): call_user_func_array('FlowHooks::onPe...', Array)
#6 /srv/mediawiki/includes/GlobalFunctions.php(4063): Hooks::run('MediaWikiPerfor...', Array)
#7 /srv/mediawiki/includes/Wiki.php(423): wfRunHooks('MediaWikiPerfor...', Array)
#8 /srv/mediawiki/includes/Wiki.php(305): MediaWiki->performAction(Object(Article), Object(Title))
#9 /srv/mediawiki/includes/Wiki.php(596): MediaWiki->performRequest()
#10 /srv/mediawiki/includes/Wiki.php(460): MediaWiki->main()
#11 /srv/mediawiki/index.php(49): MediaWiki->run()
#12 {main}
Class ResourceLoaderSchemaModule not found; skipped loading
Title::getRestrictionTypes: applicable restrictions to [[Talk:Sandbox]] are {edit,move}
OutputPage::sendCacheControl: no caching **
Comment 1 Bingle 2014-01-02 00:12:24 UTC
The WMF core features team tracks this bug on Mingle card https://mingle.corp.wikimedia.org/projects/flow/cards/669, but people from the community are welcome to contribute here and in Gerrit.
Comment 2 spage 2014-01-02 01:20:53 UTC
It happened again. I tried to reply to topic http://ee-flow.wmflabs.org/w/index.php?title=Talk:Sandbox&workflow=050b9f659413f00fc8b1fa163e68c4ac
, it failed (probably due to bug 59195), and now if you try to view the topic you get this bug.
Comment 3 spage 2014-01-02 05:32:37 UTC
Werdna and I were able to reproduce this by reverting extensions/Flow on ee-flow back to  
  1bedba6... Merge "Repair missed conversion to new username lookup"
and replying to a post on User_talk:Werdna, which failed with bug 59195, in /var/log/apache2/error.log:
   [Thu Jan 02 03:30:25 2014] [error] [client 76.14.58.232] PHP Fatal error:  Call to protected method Flow\\Model\\AbstractRevision::isAllowed()

When I then visited the post on User_talk:Werdna, it failed with this bug's error, in /tmp/debug.log:

[exception] [abe49e77] /wiki/User_talk:Werdna   Exception from line 102 of /srv/mediawiki/extensions/Flow/includes/Data/RootPostLoader.php: Missing Posts: {"2":"050d44021127f00fc8b1fa163e68c4ac"}

I'm 90% sure the page showed this error even after switching git back to master.

Yet now, a few hours later without any DB changes, all these problem pages and topics on ee-flow are now viewable with no error. Hooray, but why?

beta labs has a similar page http://en.wikipedia.beta.wmflabs.org/wiki/Talk:Flow on which as I recall I made a failed reply, and that remains in an error state:

2014-01-02 05:27:21 deployment-apache32 enwiki: [d26ecf99] /wiki/Talk:Flow   Exception from line 102 of /data/project/apache/common-local/php-master/extensions/Flow/includes/Data/RootPostLoader.php: Missing Posts: {"2":"050d408b42295cb204fa02163e0fb68f"}
Comment 4 Matthias Mullie 2014-01-02 16:40:29 UTC
Since the problem has vanished on ee-flow, I'm looking at labs now.
It's still throwing that same exception. Here's the full backtrace:

2014-01-02 15:58:38 deployment-apache32 enwiki: [41995562] /wiki/Talk:Flow   Exception from line 102 of /data/project/apache/common-local/php-master/extensions/Flow/includes/Data/RootPostLoader.php: Missing Posts: {"2":"050d408b42295cb204fa02163e0fb68f"}
#0 /data/project/apache/common-local/php-master/extensions/Flow/includes/Block/TopicList.php(248): Flow\Data\RootPostLoader->getMulti(Array)
#1 /data/project/apache/common-local/php-master/extensions/Flow/includes/Block/TopicList.php(144): Flow\Block\TopicListBlock->getTopics(Object(Flow\Data\PagerPage))
#2 /data/project/apache/common-local/php-master/extensions/Flow/includes/View.php(72): Flow\Block\TopicListBlock->render(Object(Flow\Templating), Array)
#3 /data/project/apache/common-local/php-master/extensions/Flow/Hooks.php(151): Flow\View->show(Object(Flow\WorkflowLoader), 'view')
#4 [internal function]: FlowHooks::onPerformAction(Object(OutputPage), Object(Article), Object(Title), Object(User), Object(WebRequest), Object(MediaWiki))
#5 /data/project/apache/common-local/php-master/includes/Hooks.php(199): call_user_func_array('FlowHooks::onPe...', Array)
#6 /data/project/apache/common-local/php-master/includes/GlobalFunctions.php(4032): Hooks::run('MediaWikiPerfor...', Array)
#7 /data/project/apache/common-local/php-master/includes/Wiki.php(423): wfRunHooks('MediaWikiPerfor...', Array)
#8 /data/project/apache/common-local/php-master/includes/Wiki.php(305): MediaWiki->performAction(Object(Article), Object(Title))
#9 /data/project/apache/common-local/php-master/includes/Wiki.php(596): MediaWiki->performRequest()
#10 /data/project/apache/common-local/php-master/includes/Wiki.php(460): MediaWiki->main()
#11 /data/project/apache/common-local/php-master/index.php(49): MediaWiki->run()
#12 /data/project/apache/common-local/w/index.php(3): require('/data/project/a...')
#13 {main}

Timestamp for this ID 050d408b42295cb204fa02163e0fb68f, is 2014/01/01 23:28:15.


TopicListBlock::getTopics tries to load PostRevisions based on the return value of TopicListBlock::getPage: entries from TopicListEntry storage.

I've checked the database: flow_topic_list (TopicListEntry) and flow_revision (PostRevision) have no records of the id being fetched.

This would make it look like TopicListEntry cache is out of sync with DB (and purging the cache, letting it expire, or increasing its version number should "fix" that)

Workflowloader::commit, however, has some safeguard that should make sure that cache changes are buffered until DB transaction has been successfully completed, so I'm not yet seeing any reason for the cache to be having a value that is not in DB.
Comment 5 spage 2014-01-08 19:54:27 UTC
We think a patch fixed this.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links