anomalyco/sst · error

timed out waiting for dependency install lock after 5 minute

Error message

timed out waiting for dependency install lock after 5 minutes

What it means

SST guards the shared .deps dependency cache with a per-cache-key mutex and gives up after 5 minutes of waiting. This error means another build held the dependency-install lock for the same requirements hash + architecture for over 5 minutes — usually because a competing install is genuinely stuck or extremely slow (network fetch, hung uv process).

Source

Thrown at pkg/runtime/python/build.go:844

		if !exists {
			cacheLock = &sync.Mutex{}
			globalDependencyInstallLocks[cacheKey] = cacheLock
		}
		globalDependencyInstallLocksMutex.Unlock()

		// Acquire lock with timeout (5 minutes)
		lockAcquired := make(chan struct{})
		go func() {
			cacheLock.Lock()
			close(lockAcquired)
		}()
		select {
		case <-lockAcquired:
			// got the lock
		case <-ctx.Done():
			return fmt.Errorf("context cancelled while waiting for dependency install lock")
		case <-time.After(5 * time.Minute):
			return fmt.Errorf("timed out waiting for dependency install lock after 5 minutes")
		}
		defer cacheLock.Unlock()

		// Check disk cache
		if entries, err := os.ReadDir(depsCacheDir); err == nil && len(entries) > 0 {
			if err := copyDependencyPackages(depsCacheDir, input.Out()); err != nil {
				slog.Warn("failed to copy from disk cache, will reinstall", "error", err)
				// Remove bad cache and continue to reinstall
				os.RemoveAll(depsCacheDir)
			} else {
				return nil
			}
		}

		// Cache miss - create the cache directory
		if err := os.MkdirAll(depsCacheDir, 0755); err != nil {
			return fmt.Errorf("failed to create deps cache directory: %w", err)
		}

View on GitHub (pinned to a0bd20f762)

Solutions

1. Find and kill the stuck build process holding the lock (locks are in-process): `ps aux | grep sst` and terminate the hung one, then redeploy.
2. Rerun the deploy — the second attempt may hit the now-populated .deps cache and skip the install.
3. If installs are legitimately slow, fix the underlying slowness (use a faster package index/mirror, reduce dependencies) so installs finish under 5 minutes.
4. Stagger CI jobs so they don't build the same project simultaneously.

Example fix

// before
Error: failed to copy synced dependencies: timed out waiting for dependency install lock after 5 minutes
// after
$ pkill -f 'sst dev'   # kill hung process holding the lock
$ sst deploy

// before deploying, ensure no other sst process is mid-install on this project
pgrep -f 'sst (deploy|dev)' || echo 'no competing builds'

null

try {
  await deploy();
} catch (e) {
  if (/timed out waiting for dependency install lock/.test(e.message)) {
    killStuckSstProcess();     // lock is in-process, killing frees it
    await deploy();            // second run may hit warm .deps cache
  } else throw e;
}

When it happens

Trigger: time.After(5 * time.Minute) fires in copySyncedDependencies while cacheLock is held by another concurrent build of the same project with identical requirements and architecture.

Common situations: A parallel CI job hung on a slow/unreachable package index while holding the lock; a zombie `sst dev` process mid-install; very large dependency set taking >5 minutes to install while other functions wait.

Understand the failure class

• Timeouts: ETIMEDOUT, deadlines, and hung requests — what actually expires when a request times out.

Related errors

• context cancelled while waiting for dependency install lock
• failed to generate requirements file: %w
• failed to install dependencies: %w
• failed to copy synced dependencies: %w
• failed to filter requirements: %w

AI-assisted analysis of anomalyco/sst@a0bd20f762 (2026-08-30). Data as JSON: /api/errors/fd3ee24147b77164. Report an issue: GitHub.