Last modified: 2012-03-01 02:34:29 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 T29887, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 27887 - Replying to a thread doesn't work the first time
Replying to a thread doesn't work the first time
Status: RESOLVED FIXED
Product: MediaWiki extensions
Classification: Unclassified
LiquidThreads (Other open bugs)
unspecified
All All
: Normal critical (vote)
: ---
Assigned To: Andrew Garrett
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-03-06 10:02 UTC by Niklas Laxström
Modified: 2012-03-01 02:34 UTC (History)
6 users (show)

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


Attachments

Description Niklas Laxström 2011-03-06 10:02:56 UTC
In translatewiki.net, if I reply to a thread I get "session data lost" warning. I also noticed that page changed from the individual thread to the page where the thread is on.
Comment 1 LWChris 2011-03-06 17:18:30 UTC
This behaviour does also occur when you edit a reply.
Comment 2 Purodha Blissenbach 2011-03-07 00:53:56 UTC
I observe this behavior since approximately Friday, March 4th, 2011.
Effectively, saving a reply or a new thread ceased working at once.
Instead, at leat one retry is needed now, before a save operation
becomes successful. I doubt that this is an issue related to high
server laod, or similar, since translatewiki.net moved to another,
presumably much more potent, server just some 48 hours since I am
observing this behavior, and the new server behave just like the
old one in this respect, even though its replies are now quicker.
Comment 3 Andrew Garrett 2011-03-08 12:03:11 UTC
Have you recently turned on $wgSessionsInMemCached? It seems to be caused by a discrepancy between the edit token reported by the API and the edit token that appears in the edit form.
Comment 4 Siebrand Mazeland 2011-03-13 12:00:33 UTC
No. Enabled for ages. Some recent changes by Tim are suspect:  http://www.mediawiki.org/w/index.php?limit=5&title=Special%3ACode%2FMediaWiki%2Fauthor%2Ftstarling&offset=83209
Comment 5 Tim Starling 2011-03-13 23:39:15 UTC
I don't think this is my fault, I think this is due to r82686. LqtView::doInlineEditForm() replaces $wgRequest with a FauxRequest, so $wgRequest->getSessionData() and $wgRequest->setSessionData() inevitably fail.
Comment 6 Niklas Laxström 2011-03-14 07:18:29 UTC
Funny (or not), I was wondering that revision myself yesterday:

[13:52:58]  Nikerabbit> http://www.mediawiki.org/wiki/Special:Code/MediaWiki/82686 this is unrelated, right?
Comment 7 Siebrand Mazeland 2011-03-15 12:07:40 UTC
Fixed in r84007.
Comment 8 Marcin Cieślak 2012-03-01 02:34:29 UTC
Shouldn't this be revisited now to check for possibility to use DerivativeRequest instead of FauxRequest?

FauxRequest causes problems with logging originating IP address, user agent etc.

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


Navigation
Links