Repository navigation
Fix notarization failing at random when the Apple service is slow - #772
Merged
Merged
Conversation
hannesa2
approved these changes
Oct 24, 2026
hannesa2
left a comment
hannesa2
left a comment
Contributor
There was a problem hiding this comment.
Minor non-blocking observations:
- Timeout budget: 6 attempts × (--timeout 20m + sleep 20s) ≈ up to 2h 10m. No
timeout-minutesis set for the job (default is 360 min), so this isn't critical—though it might be worth mentioning in the PR description, if this duration is intentional. - The
|| echo "notarytool wait returned early (attempt $attempt)"construct swallows any error returned bywait(e.g., network or authentication issues), not just the expected timeout. While this doesn't cause functional problems—since the subsequentnotarytool infocall will re-query the actual status—it does mean that a genuine authentication error would repeat 6 times before the loop terminates, rather than failing immediately. - Regarding
case "$STATUS" in Accepted|Invalid|Rejected): Ifnotarytool infoconsistently returnsunknown(e.g., due to a persistent API error), the loop will run through all 6 attempts before exiting with an error. This is the correct, expected behavior (not a bug). - The
plutil -extract ... -o - -command is used in essentially the same way twice (for bothidandstatus); this could be refactored into a small shell function—purely as a stylistic improvement.
Overall, this is a solid and correct fix. I would be happy to merge it as is; you might just want to briefly mention point 1 in the PR description.
Take the submission id from the JSON output of `notarytool submit` and wait for it by id, so a dropped `--wait` no longer makes the step look up the id in a half-written log. - Submit with --output-format json and read the id from it - Wait by id, polling the status again if the wait ends early - Fail the step unless the final status is Accepted - Quote the credentials and stop on the first error
goneng
force-pushed
the
notarize-by-submission-id
branch
from
October 25, 2026 05:13
db9935a to
8129498
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Take the submission id from the JSON output of
notarytool submitand wait for it by id, so a dropped--waitno longer makes the step look up the id in a half-written log.The old step ran
notarytool submit --wait | tee, then read the id withtail -3 | cut -d':' -f2. When--waitreturned while the status was still "In Progress", the last lines were the upload header, so the id came out as the zip path andnotarytool logfailed with "must be a valid UUID" (exit 64). The pipe also hid the exit status ofnotarytool, because the shell has nopipefail. This broke PR builds at random, for example run 40074816682 (x86_64) and run 40085489006 (arm64).--output-format jsonand read the id from itset -euo pipefail)Test plan:
bash -nnotarytool1.1.0 haswait,--timeoutand--output-format json