Changes have been made in Git (master):

commit a9b2d0e3a882c5dd4fb230a16fd5bbb2d2a7cc0b
Author: Michael M Slusarz <slusarz@horde.org>
Date:   Mon Oct 24 23:01:10 2011 -0600

     Bug #10677: Further improvements to missing message error reporting

     Conflicts:

             imp/lib/Ajax/Application.php

  imp/js/dimpbase.js            |    5 ++-
  imp/lib/Ajax/Application.php  |  110 
++++++++++++-----------------------------
  imp/lib/Views/ShowMessage.php |   57 ++++++++-------------
  imp/message-dimp.php          |    5 +-
  4 files changed, 61 insertions(+), 116 deletions(-)

http://git.horde.org/horde-git/-/commit/a9b2d0e3a882c5dd4fb230a16fd5bbb2d2a7cc0b

Changes have been made in Git (master):

commit 4f9ed9e0737e5d7f200ed574005460d74b2473e5
Author: Michael M Slusarz <slusarz@horde.org>
Date:   Mon Oct 24 14:27:00 2011 -0600

     Bug #10677: Remove empty objects (i.e. messages that don't exist 
on the server)

  .../Imap_Client/lib/Horde/Imap/Client/Base.php     |   26 ++++++++++++++++---
  .../lib/Horde/Imap/Client/Data/Fetch.php           |   12 +++++++++
  2 files changed, 34 insertions(+), 4 deletions(-)

http://git.horde.org/horde-git/-/commit/4f9ed9e0737e5d7f200ed574005460d74b2473e5

Changes have been made in Git (master):

commit 611e41aa413064a9b2307291f4fcfc384cc43e96
Author: Michael M Slusarz <slusarz@horde.org>
Date:   Mon Oct 24 12:52:34 2011 -0600

     Bug #10677: Catch case where message to view no longer exists

  imp/lib/Views/ShowMessage.php |   12 ++++++++----
  1 files changed, 8 insertions(+), 4 deletions(-)

http://git.horde.org/horde-git/-/commit/611e41aa413064a9b2307291f4fcfc384cc43e96

Perfect

I see the issue now... somebody (I'm guessing you - Jan - added for 
the mobile view) added a showMessage() action.  This method is 
essentially duplicative of showPreview(), so I combined the two.  The 
only difference is that when viewing a full message, errors should 
bubble to the AJAX handler while when viewing a preview message, 
errors need to be caught and handled by the preview JS display code 
(since it is possible the message is loading in the background, in 
which case the error should not be displayed).

I think this should work now.

Changes have been made in Git for this ticket:

Bug #10677: Further improvements to missing message error reporting

  4 files changed, 61 insertions(+), 115 deletions(-)
http://git.horde.org/horde-git/-/commit/85844ba939f443303dfd9e8958939c7e4e0a35b7

Getting there. It doesn't seem to throw an exception in this case 
though. What's being returned from the showMessage calls now is:
{"response":{"message":{"js":[],"mbox":"SU5CT1guVHJhc2g","uid":"1124228","error":"Angegebene Nachricht nicht 
gefunden.","errortype":"horde.error"}}}
If that's how it's supposed to return that error now, I can check for 
this in client code.

Turns out that our error handling is TOO good.  In an effort to fix 
parsing errors of fetch data, we were creating empty objects.   
However, we weren't going back to check to see if these objects were 
actually filled with data from the server, and removing them from the 
fetch() return.

See if this second attempt works better.

Changes have been made in Git for this ticket:

Bug #10677: Remove empty objects (i.e. messages that don't exist on 
the server)

  2 files changed, 34 insertions(+), 4 deletions(-)
http://git.horde.org/horde-git/-/commit/5091ba358df4b8291280bd9516a0f3bb9d9e71d7

That doesn't make a difference, because $fetch_ret[$uid] *is* set at 
this point:
array(1) {
   [254600]=>
   object(Horde_Imap_Client_Data_Fetch)#497 (1) {
     ["_data":protected]=>
     array(1) {
       [13]=>
       int(254600)
     }
   }
}

Still don't think this should be handled at the IMAP Client level 
though.  It is perfectly acceptable (and may be desirable) to do 
something like fetching a range of UIDs, without the expectation that 
any/all of those IDs actually exist.  This is the recommended 
behavior, for example, when syncing the local cache when CONDSTORE 
isn't available.

Existence checking needs to be done instead at the application level, 
where the code knows what the fetch results are actually being used for.

I'm assuming you are looking at this for the mobile view.  Try the fix 
I just committed.

Changes have been made in Git for this ticket:

Bug #10677: Catch case where message to view no longer exists

  1 files changed, 8 insertions(+), 4 deletions(-)
http://git.horde.org/horde-git/-/commit/b0275a41678b6af247ca3e1b8ddacf34060b30fd

Yes. I noticed this while using the showMessage ajax call which 
returns a complete message object in that case, but with all 
properties empty. An exception would be easier to deal with.

Guess I am not seeing what the Horde/IMP bug is?

When parsing FETCH results, we only parse a result if an untagged 
response appears (see line 4238 in Client/Socket.php).  So in a 
conversation like you provided, no fetch responses would be parsed so 
we should theoretically be returning an empty array from the fetch() 
command.

Is the issue that IMP is trying to display the message, and we are 
relying on an exception to be thrown instead of checking for array key 
existence in the return array?

If trying to view a message that has been deleted, Cyrus still returns 
OK. This is probably a bug in Cyrus, but maybe we can still catch it 
somehow? This is the dialogue:

S: * OK neo Cyrus IMAP4 v2.2.13-Debian-2.2.13-19ubuntu5 server ready
C: [LOGIN Command - username: jan]
S: 1 OK User logged in
C: 2 EXAMINE INBOX
S: * FLAGS (\Answered \Flagged \Draft \Deleted \Seen NonJunk $Label2 
$Label1 $Label3 $Label4 $Label5 Junk $Forwarded NotJunk foo AMMMa 
Consulting $NotJunk JunkRecorded $Junk Training $MDNSent 
KMAILFORWARDED KMAILTODO KMAILWATCHED KMAILIGNORED $TODO $WATCHED 
$IGNORED H3)
S: * OK [PERMANENTFLAGS ()]
S: * 164 EXISTS
S: * 0 RECENT
S: * OK [UNSEEN 161]
S: * OK [UIDVALIDITY 968256253]
S: * OK [UIDNEXT 254528]
S: 2 OK [READ-ONLY] Completed
C: 3 SELECT INBOX
S: * FLAGS (\Answered \Flagged \Draft \Deleted \Seen NonJunk $Label2 
$Label1 $Label3 $Label4 $Label5 Junk $Forwarded NotJunk foo AMMMa 
Consulting $NotJunk JunkRecorded $Junk Training $MDNSent 
KMAILFORWARDED KMAILTODO KMAILWATCHED KMAILIGNORED $TODO $WATCHED 
$IGNORED H3)
S: * OK [PERMANENTFLAGS (\Answered \Flagged \Draft \Deleted \Seen 
NonJunk $Label2 $Label1 $Label3 $Label4 $Label5 Junk $Forwarded 
NotJunk foo AMMMa Consulting $NotJunk JunkRecorded $Junk Training 
$MDNSent KMAILFORWARDED KMAILTODO KMAILWATCHED KMAILIGNORED $TODO 
$WATCHED $IGNORED H3 \*)]
S: * 164 EXISTS
S: * 0 RECENT
S: * OK [UNSEEN 161]
S: * OK [UIDVALIDITY 968256253]
S: * OK [UIDNEXT 254528]
S: 3 OK [READ-WRITE] Completed
C: 4 UID FETCH 254522 (ENVELOPE BODY[HEADER])
S: 4 OK Completed (0.000 sec)
C: 5 UID FETCH 254522 (BODYSTRUCTURE)
S: 5 OK Completed (0.000 sec)
C: 6 STATUS INBOX.horde.apps (RECENT)
S: * STATUS INBOX.horde.apps (RECENT 0)
S: 6 OK Completed
C: 7 STATUS INBOX.horde.bugs (RECENT)
S: * STATUS INBOX.horde.bugs (RECENT 0)
S: 7 OK Completed
C: 8 STATUS INBOX.horde.cvs (RECENT)
S: * STATUS INBOX.horde.cvs (RECENT 0)
S: 8 OK Completed
C: 9 STATUS INBOX.horde.dev (RECENT)
S: * STATUS INBOX.horde.dev (RECENT 0)
S: 9 OK Completed
C: 10 STATUS INBOX.horde.imp (RECENT)
S: * STATUS INBOX.horde.imp (RECENT 0)
S: 10 OK Completed
C: 11 STATUS INBOX.Privat (RECENT)
S: * STATUS INBOX.Privat (RECENT 0)
S: 11 OK Completed
C: 12 LOGOUT
S: * BYE LOGOUT received
S: 12 OK Completed