Except if it ever does, it shouldn't break things, no matter how rare.

Figured it out though and this is now completely fixed.

Changes have been made in Git for this ticket:

Bug #10403: Never save IMAP object when we are not authenticated

  1 files changed, 5 insertions(+), 3 deletions(-)
http://git.horde.org/horde-git/-/commit/3eeefeea234002f826f4da84638c14e25559c9f2

For the record, it doesn't. Though this shouldn't really happen in 
normal usage anyway.

Changes have been made in Git for this ticket:

Bug #10403: Fix Bug Number

  1 files changed, 3 insertions(+), 3 deletions(-)
http://git.horde.org/horde-git/-/commit/705e7db4801233a5713b0c43c4eba79e25b46d75

I can verify that this was the issue (at least with IMP).  For 
example, clicking on a long running listMailboxes operation (e.g. 
opening a very large trash mailbox) and then clicking on logout while 
this request was still pending would result in an imp/ entry to be 
created in the non-authenticated session when the original process 
eventually reopened the session.  The changes to Horde_Session fix 
this - sessions are marked as read-only in an access if, when 
reopened, the authentication status has changed.

I have no idea if this fixes the user-agent string issue.

FWIW,  I can reproduce this fairly consistently when I purposely 
change the user agent on my browser while testing ourmobile views. 
When the session is terminated due to the user agent check failing, 
logging back in almost always produces this error for me.

This issue is what this commit was trying to fix:

commit 7a5e21b88440674ba15d70f6c12d87f9aa71fab2
Author: Michael M Slusarz <slusarz@curecanti.org>
Date:   Thu Aug 4 12:36:02 2011 -0600

     Work around sporadic error on re-authentication to imp

     This is a total hack, but I can't figure out why this is happening.  It
     only happens on a logout -> relogin, so it might have something to do
     with an inconsistent session state during the logout phase.

Notable is that I can not reliably reproduce.  One theory: One of the 
long running actions (e.g. listing a mailbox) is in process, logout is 
called, and the long running process will write an inconsistent 
session when it reinits the session.

well, the php error only happens when we use memcache, but the problem 
I originally mentioned involving the prefs (and possibly only 
last_logintasks) happens with memcache being used or not.  (and when 
not, the error does not happen as seen in the log attached)

so my question is, What sets last_logintasks ?

Can't recall the ticket where this has previously been discussed... 
but if PHP fatal errors during the session init, this error occurs.   
It either has something to do with APC, autoloading, or a custom 
session handler.  In any case, it is irrelevant - it simply means that 
PHP fataled during initialization.

This is the only important information:
No idea how this could happen. We would need a backtrace, and you 
should watch out for earlier errors leading to that fatal error.
And this doesn't make *any* sense at all. That constant *is* defined 
in that very file.

the attachment I left is using a second folder copy of our home 
directory (where horde is located) but with file logging on and 
memcache off... normally we use memcache and it just looks like it has 
constant errors with that max_size..
but anyway, that's unrelated to the question at hand

these issues I will mention in case they are related to this:

also, possibly separate is a memcache php error i keep getting.  seems 
like it could be related to this thread? 
http://framework.zend.com/issues/browse/ZF-11463

[02-Aug-2011 10:16:23] PHP Fatal error:  Call to a member function 
getValue() on a non-object in /usr/share/pear/Horde/Themes/Element.php 
on line 114
[02-Aug-2011 10:16:23] PHP Fatal error:  Undefined class constant 
'MAX_SIZE' in /usr/share/pear/Horde/Memcache.php on line 324

I also get this problem every while in the log..
uamail HORDE: HORDE [imp] IMP_Imap: Invalid method call 
"listMailboxes". [pid 20385 on line 328 of 
"/var/www/html/home/imp/lib/Imap.php"]  but that may be from people 
failing to log in?

also this time I deleted only the pref with pref_name= 
"last_logintasks" and the user could log in again..  the pref had this 
value in it  a:2:{s:5:"horde";i:1312295560;s:3:"imp";i:1312076139;}

I have a few users who repeatedly lose the ability to view their mail. 
  Instead they get a 500 internal server error after logging in.

We log in using IMAP and here is a horde log in debug mode....  I 
can't figure it out.  This is a log of a user logging in.. somethings 
have been replaced but it's all there.. this is from our live site

After deleting the user's database entries in horde_prefs, they can 
use the application for a while.. maybe a week.