[lacymorrow]

Paperclip: LAC-6331 · GitHub: #926

What happened

The release build for v0.8.253 (run 41191714061) failed at notarization, so nothing was published. It is not an isolated failure: six release builds between 2026-10-27 and 2026-10-31 died at a notary call. v0.8.251 and v0.8.253 both have tags and no release. Everyone on the prerelease channel simply stopped receiving builds.

Run	Failed on
10-30 04:30	HTTP status code: 401. Invalid credentials
10-30 13:50	HTTP status code: 401
10-30 21:53	getaddrinfo ENOTFOUND api.github.com
10-29 23:13 / 22:17 / 15:31	HTTP status code: 401
10-29 06:24	NSURLErrorDomain Code=-1009 "offline" against appstoreconnect.apple.com/notary/v2/asp
10-27 15:01	empty notary error
10-31 10:11 (this one)	HTTP status code: 401

The 401 is not a bad password, and the ticket's premise was wrong

LAC-6331 said to hand APPLE_PASSWORD rotation to Lacy if the failure was a 401. That had already been done and did not work. APPLE_PASSWORD was replaced at 2026-10-31T08:20Z; the run two hours later 401'd on the new value.

When (UTC)	APPLE_PASSWORD	Result
10-30 04:30	old (set 09-12)	401
10-30 13:50	old	401
10-30 14:18	old	✅ success
10-31 00:46	old	✅ success
10-31 08:20	rotated	—
10-31 10:11	new	401

A credential that succeeds twice between 401s is valid. The mechanism is in the 10-29 failure, which names the endpoint: notary/v2/asp is the app-specific-password token exchange, so a runner that cannot reach Apple gets 401 Invalid credentials rather than a network error. Today's notarization failed 3.6 seconds after starting (11:04:36.9 → 11:04:40.5), at the auth exchange, before any upload — after a 50-minute compile.

So no secret rotation is needed and nothing is handed to Lacy. Flagging for Security as the issue asked, since the diagnosis concerns a signing secret: APPLE_PASSWORD is not compromised or expired, and no secret changes in this PR.

Changes

All in .github/workflows/release-tauri.yml.

1. Check the notary service, before the build. notarytool history is the smallest authenticated call there is, retried 5 times over ~3 minutes. A sustained outage now fails red in minutes instead of 50; a brief blip is absorbed. It reports 401 and unreachable distinctly, because that distinction is what decides a human's next move, and the raw error text has already misled once.
2. One retry of the Tauri build. The preflight cannot catch an outage that begins after the build starts, which is exactly today's failure. ./target is already populated in the same job, so the retry skips compilation and goes straight back to bundling — which also means a genuine compile error fails the retry in minutes rather than repeating the full build. GitHub Actions has neither step retry nor YAML anchors, so the block is a hand copy and carries a lockstep comment.
3. The report job no longer asserts a cause it cannot observe. It hardcoded "Notarization failures (HTTP 401) mean the APPLE_PASSWORD app-specific password needs replacing." That job opened Release builds are failing #926, so the ticket arrived carrying a diagnosis generated by a string constant rather than by reading the log — and a password was rotated on the strength of it. It now names the step that actually failed (from the jobs API, which answers immediately; run logs are usually still locked that soon) and states the evidence. Rewritten as a heredoc so the failure path carries no shell metacharacters; the old quoted form also indented every paragraph by 10 spaces, which GitHub rendered as code blocks.

Testing

No Rust or frontend code changed; this is workflow-only.

• actionlint clean; YAML parses and step order is correct.
• shellcheck clean on both new run blocks (shellcheck is installed locally, so actionlint's integration was live).
• Both scripts executed against stubbed xcrun/gh, covering every branch:
  • preflight: credentials accepted on attempt 1 → exit 0; fails twice then succeeds → exit 0; persistent 401 → exit 1 with the 401-specific message; unreachable → exit 1 with the network message.
  • report: rendered the real issue body for a simulated failure, confirming variable expansion, the failed-step name, and correct markdown.

Recovery of v0.8.253

Re-dispatched as run 41210696122 (--ref main -f tag=v0.8.253 -f prerelease=true, matching how release-every-merge.yml dispatches). Note that workflow_dispatch takes the workflow file from the dispatched ref while checking out inputs.tag, so once this merges, a re-dispatch of any stranded tag gets the retry.

Verification per the issue ("a published release containing the version") is tracked on LAC-6331 and not claimed here: this PR is the durable fix, the re-run is the recovery.

Follow-up filed

The structural fix is to stop using app-specific-password auth at all — App Store Connect API key auth (APPLE_API_KEY / APPLE_API_ISSUER / APPLE_API_KEY_PATH) signs a JWT locally and never touches /asp. That needs a new .p8 minted in App Store Connect, which is owner-only, so it is filed separately rather than smuggled in here.

[lacymorrow]

Verified the three assumptions this PR's retry rests on, by reading tauri-apps/tauri-action@v0's source rather than assuming:

1. The retry really is cheap. src/build.ts has no clean/rm/rimraf of the target dir, so the second attempt reuses the ./target the first one populated in the same job and skips compilation. (Grep hits for "clean" in that file are all targetInfo.platform === 'macos' comparisons.)
2. A second attempt does not duplicate the release. src/create-release.ts exports getOrCreateRelease, which calls getReleaseByTag first and updateRelease when one exists.
3. A failed attempt leaves nothing behind. In src/index.ts, buildProject() runs at line 39 and getOrCreateRelease only at line 117, so a build that dies at notarization never creates a release. That matches what we observed: v0.8.253 has a tag and no release.

Worth noting for the reviewer: index.ts already wraps getOrCreateRelease in retry(...), and uploadReleaseAssets takes a retryAttempts argument. The action's authors had already concluded that retry is the right answer for transient faults against a remote service — they just never covered the build/notarize path, which is the expensive one and the one that has been failing. This PR closes that gap rather than introducing a new policy.