[GH-ISSUE #771] Upload fails on large IPAs: default upload timeout too low + misleading error hint #210

Closed
opened 2026-02-26 21:34:01 +03:00 by kerem · 0 comments
Owner

Originally created by @mithileshchellappan on GitHub (Feb 25, 2026).
Original GitHub issue: https://github.com/rudrankriyam/App-Store-Connect-CLI/issues/771

Problem

Uploading large IPAs (~120MB) via asc builds upload or asc publish testflight fails with context deadline exceeded on individual chunk PUT requests. The same file uploads successfully via xcrun altool (Apple Transporter) at 8.7MB/s on the same network.

Error: builds upload: upload failed: upload operation 16: Put "https://northamerica-1.object-storage.apple.com/...?partNumber=14&uploadId=...": context deadline exceeded
Hint: Increase the request timeout (e.g. set `ASC_TIMEOUT=90s`).

Setting ASC_TIMEOUT=300s does not help.

Root Cause

The default ASC_UPLOAD_TIMEOUT (60s) is shared across all chunk uploads, not per-chunk.

The upload flow:

  1. builds_commands.go:285 — creates uploadCtx via ContextWithUploadTimeout(ctx)context.WithTimeout(ctx, 60s)
  2. upload.go:118 — wraps this context with context.WithCancel(ctx), inheriting the 60s deadline
  3. upload.go:198 — each chunk PUT request uses this same context: http.NewRequestWithContext(ctx, ...)

For a 120MB IPA split into ~22 chunks uploaded sequentially (default concurrency=1), later chunks hit the shared 60s deadline even though individual chunks only take a few seconds each.

Two Issues

1. Default upload timeout is too low for large files

DefaultUploadTimeout is 60 seconds (client_core.go:27). For 120MB at typical upload speeds (5-15MB/s), all chunks need ~10-25 seconds total, but with S3 latency overhead per chunk, it easily exceeds 60s.

A workaround exists (ASC_UPLOAD_TIMEOUT=300s) but users won't discover it because of issue #2.

2. Error hint references wrong env var

The error message says:

Hint: Increase the request timeout (e.g. set `ASC_TIMEOUT=90s`).

But ASC_TIMEOUT only affects API calls, not uploads. The correct env var is ASC_UPLOAD_TIMEOUT. Users will set ASC_TIMEOUT=300s, see no improvement, and assume asc can't handle their file.

Suggested Fixes

  1. Fix the error hint — when the error originates from an upload operation, suggest ASC_UPLOAD_TIMEOUT instead of ASC_TIMEOUT
  2. Increase DefaultUploadTimeout — 300s or scale based on file size (e.g. 60s + fileSize/5MB * 2s) would cover most cases without requiring env var configuration

Environment

  • asc version: latest (installed via Homebrew)
  • File size: ~120MB IPA
  • Network: stable, 70Mbps upload (confirmed by altool completing at 8.7MB/s in 14s)
  • OS: macOS 15.4
Originally created by @mithileshchellappan on GitHub (Feb 25, 2026). Original GitHub issue: https://github.com/rudrankriyam/App-Store-Connect-CLI/issues/771 ## Problem Uploading large IPAs (~120MB) via `asc builds upload` or `asc publish testflight` fails with `context deadline exceeded` on individual chunk PUT requests. The same file uploads successfully via `xcrun altool` (Apple Transporter) at 8.7MB/s on the same network. ``` Error: builds upload: upload failed: upload operation 16: Put "https://northamerica-1.object-storage.apple.com/...?partNumber=14&uploadId=...": context deadline exceeded Hint: Increase the request timeout (e.g. set `ASC_TIMEOUT=90s`). ``` Setting `ASC_TIMEOUT=300s` does not help. ## Root Cause **The default `ASC_UPLOAD_TIMEOUT` (60s) is shared across all chunk uploads, not per-chunk.** The upload flow: 1. `builds_commands.go:285` — creates `uploadCtx` via `ContextWithUploadTimeout(ctx)` → `context.WithTimeout(ctx, 60s)` 2. `upload.go:118` — wraps this context with `context.WithCancel(ctx)`, inheriting the 60s deadline 3. `upload.go:198` — each chunk PUT request uses this same context: `http.NewRequestWithContext(ctx, ...)` For a 120MB IPA split into ~22 chunks uploaded sequentially (default concurrency=1), later chunks hit the shared 60s deadline even though individual chunks only take a few seconds each. ## Two Issues ### 1. Default upload timeout is too low for large files `DefaultUploadTimeout` is 60 seconds (`client_core.go:27`). For 120MB at typical upload speeds (5-15MB/s), all chunks need ~10-25 seconds total, but with S3 latency overhead per chunk, it easily exceeds 60s. A workaround exists (`ASC_UPLOAD_TIMEOUT=300s`) but users won't discover it because of issue #2. ### 2. Error hint references wrong env var The error message says: ``` Hint: Increase the request timeout (e.g. set `ASC_TIMEOUT=90s`). ``` But `ASC_TIMEOUT` only affects API calls, not uploads. The correct env var is `ASC_UPLOAD_TIMEOUT`. Users will set `ASC_TIMEOUT=300s`, see no improvement, and assume `asc` can't handle their file. ## Suggested Fixes 1. **Fix the error hint** — when the error originates from an upload operation, suggest `ASC_UPLOAD_TIMEOUT` instead of `ASC_TIMEOUT` 2. **Increase `DefaultUploadTimeout`** — 300s or scale based on file size (e.g. `60s + fileSize/5MB * 2s`) would cover most cases without requiring env var configuration ## Environment - asc version: latest (installed via Homebrew) - File size: ~120MB IPA - Network: stable, 70Mbps upload (confirmed by altool completing at 8.7MB/s in 14s) - OS: macOS 15.4
kerem closed this issue 2026-02-26 21:34:01 +03:00
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/App-Store-Connect-CLI#210
No description provided.