Page MenuHomePhabricator

Replying to a thread doesn't work the first time
Closed, ResolvedPublic


In, 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.

Version: unspecified
Severity: critical



Event Timeline

bzimport raised the priority of this task from to Normal.Nov 21 2014, 11:35 PM
bzimport set Reference to bz27887.

lwchris wrote:

This behaviour does also occur when you edit a reply.

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 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.

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.

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.

Funny (or not), I was wondering that revision myself yesterday:

[13:52:58] Nikerabbit> this is unrelated, right?

Fixed in r84007.

saper added a comment.Mar 1 2012, 2:34 AM

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.