Today I ran across: https://www.mantisbt.org/docs/master/en ... oting.html
The information there primarily appears to tell a site administrator how to try to reduce possibility of occurrence, or to disable the token check altogether (not recommended). Also indicated is that
So once again I find myself in a situation where I cannot access our internal MantisBT session. This is a somewhat rare occurrence, so our server setup isn't "terrible", but, this is a very significant time drain when it happens. For the life of me I cannot figure out how to reset the error condition from a client-side point of view (i.e. without meddling with the php-fpm pools (or whatever other server-side stuff is involved). Besides, the server runs all sorts of other php stuff that cannot sustain server-side intervention that is not focused explicitly on the session that is broken.Unfortunately, this problem cannot be fixed without a major rework of the way sessions and form security are handled in MantisBT.
I routinely leave the MantisBT site open in Brave... days at a time... and even then, I never really "close" the tabs and let Brave reload them. This works most of the time very reliably. I'm not sure what the difference is when it doesn't work, but today I find myself unable to "reset" the condition. I close the browser, flush history for that site, and even got a bit heavy handed and deleted stuff from the last hour of browsing... cookies and stuff. I do not want to totally flush my browser of everything. I log out. Clean stuff as best I can, but chrome-based browsers don't have the "forget this site" feature, so who knows if it is really clean. Log in, even try unchecking boxes on the MantisBT login, etc. Nothing I do will get rid of Application Error #2800. I presume that if I wait some unknown amount of time with no ManisBT window open in the browser that maybe sometime much later, it will just start working again, but I really don't know that.
So here's the thing... It'd be nice to have some kind of user-side help/mitigation guide that actually might have half-a-chance at letting users know what to do, and not just server administrators. I mean, most users aren't going to have any kind of pull with the server admin to intervene on the server side, but this is a COMPLETELY disruptive issue for the user. Apparently MantisDB declines to do the "major rework" to fix the underlying issue, so it seems to remain to the user to just deal.
I have found that if I go to a different browser that I never use, Application Error #2800 isn't seen in that browser. I have, however, also been in work situations where I didn't have the option of using another browser due to IT policies. Regardless, such a "hint" in a user-centric help document seems reasonable to at least mention even if nothing else can be suggested for a user to try.
I'd like to encourage making known some kind of user-centric resource for dealing with this error condition... spelling out what one might do to get around it... mentioning issues... i.e. losing history, site logins, etc. if such requires total reset of the browser environment, etc. I think this tracker is really cool, but I also find it extremely aggravating when it wastes so much time because something trashed my session.