Hi Mark, yes I recall running over whilst searching this issue your post or similar somewhere that this issues had been logged with Apple. Thanks for doing this back in November. We have only seen this since December when we migrated all out production stuff from OS X 10.9.5 to 10.10.1.
AN adjuct to this albeit “noise” was that SOME OS X 10.7.x Apple Script mail terms caused -11000 and -10000 failures with “assertion” errors and “thread out of line” messages and Apple resolved this expeditiously at the time. Although, I am surprised that seeing a fair few of us have had this issue that it was not seen during Yosemite beta testing…
I agree with your own findings that this is a DEFECT in the processing of the term “mail attachments”. I’d like a workaround of course.
Alas we will have to wait and deal with our situation manually as we rely somewhat on APPLE Mail rules.
All, thanks again for your comments and ideas.
I will update this thread and close it once a satisfactory resolution is found.
Don’t know why but I was hoping that since apple have screwed some of the commands in JXA , like not being able to get the album art using rawdata of data for iTunes. Then maybe they had done the reverse here.
So tried it.
Mail = Application('Mail')
var theAtt =Mail.selection()[0].mailAttachments()[0].name()
theAtt
//--On My Mac mailbox: --> "photo 1.JPG"
//--iCload mailbox: --> Error -10000: AppleEvent handler failed.
And pretty much the same results. Same email but one stored in mailbox ‘On My Mac’ and one in the inbox (icloud)
Hi Mark, that’s also very interesting. Thanks for that post. This flaw in the “mail attachment” term processing will have to be addressed by an Apple OS X internal s/w fix and I have resigned to having to wait for it.
BTW for you and other readers the continued thread fro Apple forums user twtwtw has some reasonable views concerning this issue.
Hi Shane, yes fair point! yeah this has been logged apparently by a few people since November 2014, including one of the people in this thread. Two people have pointed out that it has been accepted or made a DUPLICATE or some terminology that means it has been acknowledged as a defect by Apple.
[whinge] I hope it’s resolved soon OS X 10.10.2 because the production workflows we use from clients has some reliance on this term “mail attachment” in our mail rules.
point 1 : I sent my own report
At this time it’s not flagged as a duplicate. Maybe because the given details made a difference.
point 2 : At this time the problem is always striking in the late 10.10.2 beta version.
Yvan KOENIG (VALLAURIS, France) vendredi 23 janvier 2015 11:10:07
Running the simplest script throws a -10000 error for any reference to “mail attachments.” Since the base access to attachments is broken, am I correct in assuming that any and all scripts to automatically save our incoming attachments to a “downloads” folder are impossible?
Simple to reproduce; Select a mail item with attachments and run the following simple script with Scriptp Debugger:
tell application “Mail”
set theMessages to selection
repeat with thisMessage in theMessages
set theAttachments to thisMessage’s mail attachments
end repeat
end tell
Yes sadly it is not fixed (still problematic) in OSX 10.10.4
It however is an inconsistent circumstance. I share the thought it is definitely “cache” related. The hit and miss is very difficult to set up a test and the information is still the “-10000” event regardless of the syntax used to pull the attachments(s) by message
The assertion error logging is also inconsistent.
I’m looking for a workaround because this error has been an obstruction to some production workflow since we migrated to OS X 10.10 last year
Just to add $.02. I’m having the same problem with this code snippet, which (for now) simply wants to count the number of attachments in the current selection. If each time I just select one message with a single attachment, for some messages the script works, but others throw the dreaded -10000 error. In the code below, with some messages the display dialog with “attachmented” never happens.
set selectedSize to 0 as integer
set attachmentCount to 0 as integer
tell application "Mail"
try
set selectedMessages to selection
end try
end tell
set selectedCount to count of selectedMessages
display dialog "here 1" -- DEBUG
with timeout of (30 * 60) seconds
repeat with theMessage in selectedMessages
tell application "Mail"
try
display dialog "here 1a" -- DEBUG
set selectedSize to selectedSize + (message size of theMessage)
display dialog "selectedSize: " & selectedSize -- DEBUG
set theAttachments to the mail attachments of theMessage
display dialog "attachmented " -- DEBUG
on error errStr number errorNumber
display dialog "Error in theAttachments:" & return & ¬
"errStr: " & errStr & return & ¬
"number: " & number & return & ¬
"errorNumber: " & errorNumber
error errStr number errorNumber
end try
end tell
set attachmentCount to count of theAttachments
end repeat
end timeout
Model: iMac
AppleScript: (Xcode) 2.4
Browser: Chrome 44.0.2403.155
Operating System: Mac OS X (10.10)
Hi Swampman, yes these similar snippets of applescript always yield the same result - the “-10000” apple event issue.
FWIW, it is NOT consistent despite my comment above. Interestingly its point more to a “cache” related scenario. Right now we DONT see this issue. It will occur again soon though.
I’ve upgraded to  OSx 10.10.5 on clients and also the servers and it still happens.
It rather seems to be related to some TIMING or access.
As you point out merely attempting to derive a COUNT of attachments manifests this error.
I am trying to determine what the “assertion” issue is when it happens. No info sadly at this stage.
And… for the story here, this happens ALSO email accounts that are hosted on my own OSx server using OSX server mail server. so it’s unrelated specifically to iCLOUD or any other email server/service. It just seems to manifest itself on OSX in both automator environment and Applescript.
As I am curious, I will import the message in El Capitan to check if it errors also in it.
Mauybe useful for you:
The Console reported the oddity with :
20/08/2015 15:28:56,521 Mail[259]: *** Assertion failure in -[MCMimeBody dataForMimePart:], /SourceCache/Mail/Mail-2104/MailCore/MIME/MCMimeBody.m:362
20/08/2015 15:28:56,522 Mail[259]: An exception was thrown during execution of an NSScriptCommand…
20/08/2015 15:28:56,522 Mail[259]: This method must be called off the main thread
Yvan KOENIG running Yosemite 10.10.5 in French (VALLAURIS, France) jeudi 20 août 2015 15:27:06
I’m running the script against messages stored in my inbox, which combines messages from different iMap servers. So I agree the problem is probably not server-specific, although I have to test this by selecting messages I know come from different servers.
But since the problem is sporadic, a limited amount of testing cannot prove the problem is server-specific or that it no longer exists.
Nonetheless, in my limited testing, the problem has been consistent. One message with an attachment always triggered the error, while another message with an attachment never did.
Following a suggestion on this board, I rebuilt the indices for my Mail app. The message that always triggered the error no longer does.
Although not a genuine workaround, here’s how I intend to deal with this issue for the time being. (1) Keep the error trap in place, although modify it to keep track of which messages trigger the error. (2) For messages without attachments, use my app as designed. (3) For messages with attachments, use the error trap to monitor their behavior and deal with problematic messages individually, on a case-by-case basis. (4) Curse Apple frequently :D.
Some slightly good news on the issue and a simple workaround that can be added to automator script or applescript. It seems the -10000 apple events error and the “assertion” error have a relationship to some failed access to cases on the IMAP server. This is anecdotal only.
This is on OSX 10.10.5 …
We have managed to implement a simple work around that involves using Application “Mail” to
Step 1. move the mail message being processed to another mail folder in the current mail account or similarly move to another mail account and mailbox.
step 2. accessing that email that now has a new message id since it was moved
step 3. processing that email in Step 2. to “get mail attachments for this_message”
step n.etc … resume the processing using the mail messed id from 2.
It seems that logically MOVING the message and attachments within mail, causes the addressing to the attachments for “count” and “get” to be quite solid.
For example, this code snippet is framed within Application “Mail”, with email account “Production imap account”, with an INBOX folder names “transient”.
The full reference to the email account and inbox and folder (mailbox “INBOX/transient” of account “Production imap account”) is here for example. rather than using a default account. This you can move it anywhere. We have succeeded to also use “On My Mac”. The latter is no good for our production work.
NOTE: This wont work using a mail “move” directive in a mail rule because the new mail reference is lost.
This must be done within the script as shown below with these 2-3 lines of applescript statements.
(* move the message and attachments to another mailbox *)
move the current_msg to mailbox "INBOX/transient" of account "Production imap account"
(* address/reference the moved email message - care... it has a Newly created message id! *)
set moved_message to first message in mailbox "INBOX/transient" of account "Production imap account"
(* Re-address the (your) current code_variable with the MOVED email and its attachments. *)
set current_msg to moved_message
(* the existing code continues.*)
tell current_msg
-- the rest if the code you use goes here. et
This has been working solidly in existing workflow now to handle applescript mail attachments. So there are no more “-10000 apple event” errors!
I was getting the same -10000 error when trying to handle mail attachments. I had thought, after getting some help on my thread, that there must be an issue with some of the mail messages that I was testing it on, as the script still worked on other messages. Believing it to be fixed I went away happy, only to find tonight that the problem had not gone away.
I was running 10.11.3, and still getting the error, which doesn’t coincide with your experience above. I have now updated to 10.11.4 but it is still present.
However, the good news is that your workaround works perfectly and my problem is solved. In my case it is only one script that I needed to fix, but one that I use often to save me a lot of time, that had cause a great deal of frustration when it stopped working.
Thank you so much for posting your solution. It has really saved the day.