i looked and looked to figure out how the first issue could be happening. I only have a theory.
background: the function in question relies on 'session's' data collected by your use and stored in the session's memory. I also leverage cache's to speed the site up and take a bit of burden off the server.
theory: the session's information stored on you is held in suspension (ram) instead of written to a file, and the cache updates every time you do something that requires a session statement. What i 'think' may be happening is the 'current' page isn't stored in the session until you leave it and log in... and post successful login the script tell the browser to return you to your last know page (queries the cache) and the cache reports the last page you left being the 'next' previous instead of the most previous.
If this is so, i don't know how to defeat this. one way for me to know if it's so is by your response to this question: "when it takes you to an unintended thread, was or is it a thread you were in before?"
next one:
the sessions timeout...
so I use a RAM held session as opposed to writing the data to a file. I do this for security- my strategy being "if someone attempts to break into the site by using valid sessions stolen from someone else (a user) they're NOT going to find them by breaking into a directory that stores files... they'll have to somehow negotiate and collect information that's stored in RAM, which is virtually impossible".. As it turns out, the RAM held sessions doesn't take directives from any of the 'timing' directives- it operates, by design, on it's own. it's valid until the machine loses it's RAM (flushes it) for some reason. Other than that happenstance, there is a 'gc_' (garbage collection) function that randomly flushes sessions 50 times every 100k logs. this is done to keep the RAM segment/cluster clean and clear, as well as to re-challenge users.
over the weekend i did some things to the page in effort to remedy this, and while looking found some other things that could likely be better done in RAM as opposed to I/O on a disk... so i migrated a metric ton (technical term is 'shit ton') of stuff to be operated by the servers RAM to reduce i/o on the disk. I upped the sessions lifetime by decreasing the garbage collection rate. I hope it works, as otherwise and in effort to remedy your request i'll have to go back to using files as a sessions storage, and i really don't want that vulnerability on the site.
