Team ID: RSNGKW5LNH
I have a matched pair submitted seconds apart that I cannot explain, and I think
it shows a service-side problem rather than one in my bundle.
Submission Contents Result
359b004e-ccd2-4ab0-a02e-0516b5598b75 a signed Node binary + 2,000 identical one-line text files In Progress for 36+ minutes
e4abe4b5-8829-47fb-aa1c-6a79d6824094 the same signed Node binary + a full 7,900-file npm dependency tree Accepted in 87 seconds
Both created 2026-08-13 at 05:40Z, submitted in the same loop, same signing, same
ditto -c -k --keepParent, same notarytool invocation. The trivial one hung;
the complex one cleared.
The first fixture is as innocuous as a submission gets — one Developer ID signed
Node binary and 2,000 copies of a file whose entire content is
// inert fixture stub. I can regenerate it from a script and share it.
Eight of fifteen submissions tonight are still In Progress, the oldest at 78
minutes, spanning every shape I tried: with and without the dependency tree, with
and without a signed binary, plain and encrypted inner archives, 11MB to 60MB,
high-entropy and trivially compressible. WWDC21 session 10261 states a commitment
to 15 minutes for 98% of submissions.
WWDC21 session 10261 says Apple is "committed to completing this process within
15 minutes for 98 percent of Notary submissions, and most complete in under
five." My cleared submissions match that — 19 to 113 seconds. The affected ones
ran past five hours and were then deleted.
I ran a 21-submission bisection with a decision rule fixed in advance (still In
Progress at 10 minutes = hung; in practice the results were bimodal, with nothing
at all between 113 seconds and 36 minutes). Each fixture differed from its neighbour by one
property. Cleared, and so exonerated: the submission channel (31s), byte volume
(108MB Node runtime alone, 44s), the Mach-O binaries themselves (9.9MB esbuild
alone, 19s), file count (11,001 stubs, 110s), the name node_modules (108s),
@-scoped directories, nesting depth, and directory count. Still hung after:
pruning unused files, dereferencing all 222 symlinks, flattening the tree, and
sealing it inside an inner zip.
Two things make me think this is not a signing mistake on my side.
First, a matched pair. A fixture containing an unsigned binary nested inside an
inner zip came back Invalid in 113 seconds, with the log naming the offending
path three times. Its pair — same layout, submitted two minutes later, differing
only in that the nested binary was signed — has never returned anything. When the
notary has something to say it says it quickly and precisely, and it descends
into nested archives.
Second, the stuck submissions are deleted. Seven were confirmed In Progress
at 2026-08-12T07:13:12Z. Re-queried 21–26 hours later, all seven return
"Submission does not exist or does not belong to your team" and none appears in
notarytool history, while submissions from the same minutes under the same
credentials still resolve — a978eb1f-d781-4fdc-9295-88540a37a504 (05:49:24Z)
still returns Accepted; f991e71b-742e-4a7d-a47c-48809a60b321 (05:10:08Z) is
gone.
Two questions:
Can anyone see what is happening to 359b004e-ccd2-4ab0-a02e-0516b5598b75?
Given what is in it, I do not think there is anything in the archive to find,
and its same-batch pair completing in 87 seconds suggests the service was
healthy at that moment. Happy to provide the generating script, digests, or
the full fifteen-submission ledger.
Should a submission that cannot be processed disappear rather than reaching a
terminal state? As it stands there is no way to tell "queued" from "will never
complete," and the ids needed to report it expire before a support cycle
finishes.
The submission above is not my app — it is a fixture generated by a script,
containing only my own JavaScript files and no Mach-O at all. I can describe its
contents exactly, and regenerate it on request. I also have matched fixtures that
differ only in directory naming, and a variant sealed inside an encrypted inner
archive, if any of those would help narrow it.
