[GH-ISSUE #644] Edge case: SignTools times out before CI finishes when developer account is unusually slow #122

Closed
opened 2026-03-04 00:24:06 +03:00 by kerem · 6 comments
Owner

Originally created by @jluo98 on GitHub (Feb 21, 2026).
Original GitHub issue: https://github.com/SignTools/SignTools/issues/644

!! Please fill in this template, DO NOT ignore or delete it. !!

I tried basic troubleshooting first

Describe the bug

SignTools has a built-in timeout that's not tied to the result of a running CI job.

When the CI job runs longer than the default timeout (developer account, contacting Apple server, not actually failing), even when the run was successful, the upload would fail with an 404 error.

To reproduce

Steps to reproduce the behavior:

  1. Sign an IPA with developer account and GitHub Actions
  2. The CI run takes longer than around 15 minutes
  3. Refresh SignTools web page, the app entry turns red
  4. CI eventually finishes, but fails to upload the signed IPA, error 404

Expected behavior

SignTools waits for the CI to run instead of timing out early.

Logs

If possible, please include logs.

SignTools: https://pastebin.com/A4PdpccG
SignTools-CI: https://pastebin.com/meHceWic

Screenshots

N/A

System configuration

  • SignTools version: 3.0.11
  • Installation type: cloud server; traefik
  • Operating System: Ubuntu 24.04.4 LTS
  • Builder type: SignTools-CI
  • Builder version: 28d2f6e (template), a0be548 (personal repo using templat)

Additional context

N/A

Originally created by @jluo98 on GitHub (Feb 21, 2026). Original GitHub issue: https://github.com/SignTools/SignTools/issues/644 !! Please fill in this template, DO NOT ignore or delete it. !! **I tried basic troubleshooting first** - [X] Updated **both** [SignTools](https://github.com/SignTools/SignTools) **and** the builder ([SignTools-CI](https://github.com/SignTools/SignTools-CI) or [SignTools-Builder](https://github.com/SignTools/SignTools-Builder)) to the latest version - [X] Read through the [FAQ page](https://github.com/SignTools/SignTools/blob/master/FAQ.md) **Describe the bug** SignTools has a built-in timeout that's not tied to the result of a running CI job. When the CI job runs longer than the default timeout (developer account, contacting Apple server, not actually failing), even when the run was successful, the upload would fail with an 404 error. **To reproduce** Steps to reproduce the behavior: 1. Sign an IPA with developer account and GitHub Actions 2. The CI run takes longer than around 15 minutes 3. Refresh SignTools web page, the app entry turns red 4. CI eventually finishes, but fails to upload the signed IPA, error 404 **Expected behavior** SignTools waits for the CI to run instead of timing out early. **Logs** If possible, please include logs. SignTools: https://pastebin.com/A4PdpccG SignTools-CI: https://pastebin.com/meHceWic **Screenshots** N/A **System configuration** - SignTools version: 3.0.11 - Installation type: cloud server; traefik - Operating System: Ubuntu 24.04.4 LTS - Builder type: SignTools-CI - Builder version: 28d2f6e (template), a0be548 (personal repo using templat) **Additional context** N/A
kerem 2026-03-04 00:24:06 +03:00
  • closed this issue
  • added the
    bug
    label
Author
Owner

@jluo98 commented on GitHub (Feb 21, 2026):

The log I attached came from the latest run. This run actually ended with a cancelled CI instead of a failed upload.

<!-- gh-comment-id:3939708567 --> @jluo98 commented on GitHub (Feb 21, 2026): The log I attached came from the latest run. This run actually ended with a cancelled CI instead of a failed upload.
Author
Owner

@jluo98 commented on GitHub (Feb 22, 2026):

Did another test. Using Github Actions is taking over 30 minutes and the run gets cancelled before it finishes. Using a self-hosted Mac, the job finishes within minutes, completely normally. Github's machines seem to have some kind of throttling problem reaching Apple's servers.

Again, I'd consider this an edge case, a fix is not necessary, but nontheless beneficial.

<!-- gh-comment-id:3940270678 --> @jluo98 commented on GitHub (Feb 22, 2026): Did another test. Using Github Actions is taking over 30 minutes and the run gets cancelled before it finishes. Using a self-hosted Mac, the job finishes within minutes, completely normally. Github's machines seem to have some kind of throttling problem reaching Apple's servers. Again, I'd consider this an edge case, a fix is not necessary, but nontheless beneficial.
Author
Owner

@ViRb3 commented on GitHub (Feb 22, 2026):

Yes, there are hardcoded unconditional timeouts:

These are there because sometimes things can stall forever, and you don't want to burn credits or even money endlessly. If you want, you can change those as you please on your personal SignTools-CI copy. In my personal experience, nothing has ever taken close to 30 mins, unless there's an underlying problem which should be addressed instead.

<!-- gh-comment-id:3941402844 --> @ViRb3 commented on GitHub (Feb 22, 2026): Yes, there are hardcoded unconditional timeouts: - https://github.com/SignTools/SignTools-CI/blob/master/.semaphore/semaphore.yml#L7-L8 - https://github.com/SignTools/SignTools-CI/blob/master/.github/workflows/sign.yml#L9 These are there because sometimes things can stall forever, and you don't want to burn credits or even money endlessly. If you want, you can change those as you please on your personal SignTools-CI copy. In my personal experience, nothing has ever taken close to 30 mins, unless there's an underlying problem which should be addressed instead.
Author
Owner

@jluo98 commented on GitHub (Feb 22, 2026):

@ViRb3 yes the 30 minute timeout makes total sense for CI runs and shouldn’t be changed.

But on the SignTools side, it times out (turns red) way before that, I believe around 15 minutes.

One of my runs took around 20 minutes to complete, but by then SignTools already closed the upload path so the job failed with a 404 error. I’m referring to this situation.

Edit: but you’re absolutely right. A run shouldn’t take this long anyway. GitHub’s machines probably had some problems yesterday/recently that if using a developer account, it’s taking absolutely forever to get all the entitlements from Apple.

<!-- gh-comment-id:3941538731 --> @jluo98 commented on GitHub (Feb 22, 2026): @ViRb3 yes the 30 minute timeout makes total sense for CI runs and shouldn’t be changed. But on the SignTools side, it times out (turns red) way before that, I believe around 15 minutes. One of my runs took around 20 minutes to complete, but by then SignTools already closed the upload path so the job failed with a 404 error. I’m referring to this situation. Edit: but you’re absolutely right. A run shouldn’t take this long anyway. GitHub’s machines probably had some problems yesterday/recently that if using a developer account, it’s taking absolutely forever to get all the entitlements from Apple.
Author
Owner

@ViRb3 commented on GitHub (Feb 23, 2026):

The client-side timeout can also be set freely, via the SignTools yml config:

github.com/SignTools/SignTools@4efbeea62c/src/config/config.go (L84)

It's set to 30, matching SignTools-CI.

<!-- gh-comment-id:3942140549 --> @ViRb3 commented on GitHub (Feb 23, 2026): The client-side timeout can also be set freely, via the SignTools yml config: https://github.com/SignTools/SignTools/blob/4efbeea62cf84c10183de1d6d7477bb267b28113/src/config/config.go#L84 It's set to 30, matching SignTools-CI.
Author
Owner

@jluo98 commented on GitHub (Feb 23, 2026):

Oh you're right, I had mine set to 15 a long time ago and forgot about it. Thanks for pointing that out! I'll close this issue now.

<!-- gh-comment-id:3942145925 --> @jluo98 commented on GitHub (Feb 23, 2026): Oh you're right, I had mine set to 15 a long time ago and forgot about it. Thanks for pointing that out! I'll close this issue now.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/SignTools#122
No description provided.