0011023: Application error 2800 on subsequent bug reporting - MantisBT

ID	Project	Category	View Status	Date Submitted	Last Update
0011023	mantisbt	bugtracker	public	2009-10-08 15:45	2012-01-11 14:32

Reporter	javatopia	Assigned To	dregad
Priority	normal	Severity	major	Reproducibility	always
Status	closed	Resolution	no change required
Platform	IE8	OS	Windows	OS Version	XP,Vista
Product Version	1.1.8

Summary	0011023: Application error 2800 on subsequent bug reporting
Description	We get the error 2800 each time we try to submit a second bug consecutively. We are not going "back" to the submission form, but rather clicking on the "Report Issue" link and starting with a fresh page.
Steps To Reproduce	Submit a bug Click on Report Issue Fill it out and submit Observe error 2800 Click "logout" Login Click on Report Issue Use the same data as in 3, and submit Observe repeat of 4. Close tab panel in IE8 and re-open mantis go to 6 I could only report another bug if I terminated my IE8 application (close the window entirely) and re-open with mantis. This happens consistently in 1.1.8, it also appeared in 1.1.6
Tags	No tags attached.

lemonad 2011-11-10 10:35 reporter ~0030213	We have the same problem in 1.2.5. Users were reporting that on the second bug report in a row, they got the #2800 error. I did some research and it seems to be caused by "bug_report_token" in forms not updating after the first entered bug. It also seemed related to IE as I could not reproduce the problem in Firefox. It might also be related to proxy caching but I'm not so sure about that, it could be caching in general. The thing is that I was looking at the last-modified header when I noticed that the server clock was several hours ahead and after fixing that, I cannot reproduce the problem. If the problem returns, I'll add more information.

AbsolutelyFreeWeb 2011-12-23 23:07 reporter ~0030681 Last edited: 2011-12-24 01:43	also a problem in 1.2.8 work around, use "check to report more issues" checkbox and push the button "report another issue" on the next page. the checkbox and button are not needed if you just fix this bug imho

dregad 2011-12-24 09:10 developer ~0030697	AbsolutelyFreeWeb can you confirm the provided steps to reproduce allow to replicate the problem in 1.2.x? If not, please provide new steps, and specify which platform you're using. Did you check the last-modified header timestamp vs server date, as indicated by lemonad ?

AbsolutelyFreeWeb 2011-12-26 02:00 reporter ~0030701	thanks dregad. I should have paied more attention to lemonads post. my computer (the client) showed yesterdays date. So basically I had the same problem as lemonad, but this time it was not the server clock, but the client clock that was wrong.