"Processing delayed due to a service issue" ?

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.

Replies

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

.zip
files in some weird way? Or using Apple tools (
ditto
or Finder > File > Compress)?

The reason I ask is that I downloaded the

notarizefail_12761838.zip
file from your bug report and it unpacked just fine, but when I double click
test7/***.zip
(I’ve elided the exact name for privacy) to unpack that, the Archive Utility gets halfway through the job and then hangs. This is on 10.14.6.

Curiously, if I move

test7/***.zip
to 10.15, it unpacks just fine. If I then re-create the Zip archive using Finder > File > Compress and move it back to 10.14.6, that unpacks there. Which is why I’m suspicious that it’s related to the way you created this Zip archive.

It 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"

  • Thank you for your hint! I had non-Latin letters in both: app wrapper and app's binary. I removed it from app's binary and it worked as a charm :)

  • Yay!

Add a Comment