One of our pkgs has been put in notarization limbo a few times (slightly different builds each time) with the status "Processing delayed due to a service issue". The oldest instance it over 2 days old, so I'm not confident that it will ever complete.
What can we do about this? I've read posts about long delays in notarization that seem to involve service outage, but this seems a bit different. Apple has inserted itself into our build/distribution process in a most inconvenient way.
What was the request UUID?
Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware
let myEmail = "eskimo" + "1" + "@apple.com"This is the one that's a few days old: 786837c6-e9af-4732-aa42-49973acedada
Here's the more recent one: f9444a87-f3c8-4e15-882f-da558c547623
Thanks
Bug submitted: FB7395461
From that bug report:
I've narrowed the problem down to a small test zip archive (we are notarizing pkgs, but I thought the zip test would be a simpler demonstration of the problem). The zip contains a folder with a simple .app, and a zip archive that contains a few JavaScript source files and a few .json files. If I just put the app in a zip it notarizes fine -- it's only there so the zip is considered "valid" by the notarization service. Also, if I expand the internal zip and just include the files directly in the container zip, notarization works.
Bug submitted: FB7395461
Thanks for that. I had actually run your question past the notarisation folks and they’d already pointed me the direction of that specific Zip archive. There’s something about it’s format that’s causing the notarisation servers to chuck a wobbly. This is definitely a problem at our end, so filing a bug was the right call.
Are you creating these
.zipdittoThe reason I ask is that I downloaded the
notarizefail_12761838.ziptest7/***.zipCuriously, if I move
test7/***.zipIt also suggests a possible workaround, namely, change the way that you create this Zip archive.
ps Please update your bug with your results as well, to make it easier for the notarisation team to see them.
Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware
let myEmail = "eskimo" + "1" + "@apple.com"Thanks for looking into this. I'll update the bug with info as you suggest. Thanks again!
You should be able to address it by just re-zipping the files in question. Then processing for your package can continue, since it only that one extremely specific file causing the submission to be invalid.
yup, understood. thanks.
I'll also add info to the bug report. the zip file is valid, but includes some unnecessary PK tags for the directory entries. the resulting zip file is valid, but clearly throws a wrench into some extraction tool used by the notarization service.
Today I recieved error with status code 3 and message: "Processing delayed due to a service issue". Thankfully, I come across this thread! And didn't loose time and waiting few days pulling hair out of the head wondering when will Apple finally solve this server issue! And I would wait and pulling hair 'cause email I got from the service says: "The Mac software that you uploaded was not processed due to a service issue. Once we resolve the issue, processing will continue. You do not need to upload again." So, once again, thanks for this thread :)
Apple, you should really change these messages!
To get to the point, I was searching what could be wrong and finaly found a reason: I was using non-english letters in the name of my app. Altough, non-english letters are accepted in Application folder on MacOS, obviously notarization can't chew it and breaks.
I don't know how to submit this bug, so I leave here RequestUUID fbb7b957-70f3-4115-8974-202d68bb6f4e and someone somehow will submit this bug. (or please point me how to submit it :)
Thank you all!
please point me how to submit it
Use Feedback Assistant to file bugs against the notary service.
Please post your bug number, just for the record.
Altough, non-english letters are accepted in Application folder on MacOS, obviously notarization can't chew it and breaks.
Were the non-Latin letters in the app wrapper (Foo.app)? Or in the app’s binary (Foo.app/Contents/MacOS/Foo)?
Non-Latin letters in the app wrapper won’t cause problems. Non-Latin letters in the app’s binary can cause problems on the Mac due to the way that code siging deals with Unicode normalisation (r. 68829319).
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"