anomalyco/sst · warning

context cancelled while waiting for dependency install lock

Error message

context cancelled while waiting for dependency install lock

What it means

SST serializes dependency installs per cache key (requirements hash + architecture) with an in-process mutex so concurrent function builds don't race on the shared .deps disk cache. While blocked waiting for that lock, if the build context is cancelled (Ctrl-C, deploy timeout, parent context closed), this error is returned instead of hanging.

Source

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

		globalDependencyInstallLocksMutex.Lock()
		cacheLock, exists := globalDependencyInstallLocks[cacheKey]
		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 {

View on GitHub (pinned to a0bd20f762)

Solutions

1. Simply rerun the deploy — the error is a cancellation, not corruption.
2. Avoid running multiple concurrent deploys of the same project (they contend on the same lock and .deps cache).
3. If CI timeouts cause it, raise the job timeout so the install can finish.
4. If a process was force-killed while holding the lock, restart the CLI process (locks are in-process, so a new run is clean).

Example fix

// before
# terminal 1: sst deploy (installing...)
# terminal 2: sst deploy  -> Ctrl-C / cancel -> context cancelled while waiting for dependency install lock
// after
$ sst deploy  # run one deploy at a time, or wait for the first to finish

null

null

try {
  await deploy();
} catch (e) {
  if (/context cancelled while waiting for dependency install lock/.test(e.message)) {
    // expected on Ctrl-C / cancel; just wait for the other build then retry
    await waitForOtherBuildToFinish();
    await deploy();
  } else throw e;
}

When it happens

Trigger: ctx.Done() fires while another goroutine/build holds cacheLock in copySyncedDependencies — e.g. `sst deploy` cancelled mid-build while another `sst deploy`/`sst dev` builds the same project concurrently.

Common situations: User hits Ctrl-C during a long install; CI job killed by timeout while a parallel job holds the lock; `sst dev` restart triggered while deploy is installing deps.

Related errors

• timed out waiting for dependency install lock after 5 minute
• 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/1aada71b20e283eb. Report an issue: GitHub.