Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

Apple runner cache under ~/.agent-device/apple-runner grows without bound (4.4 GB measured)

Ouverte
  • Quelque chose ne va pas ?
#3,246 1 commentaire 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

@janicduplessis y travaille déjà.

Depuis le 6/10/2026.

  • #3247 par @janicduplessis — ouverte

Évaluation

Difficulté
4/5
Temps estimé
3-5 jours
Accessibilité débutants
35/100
Type d'issue
Fonctionnalité
Clarté
Clairement spécifiée
Activité
À l'abandon
Stack technique
typescript
Domaine
devtools, tooling

Piste de recherche

Start by reading resolveRunnerDerivedPath, cleanRunnerDerivedArtifacts, and tryReuseExistingXctestrun, along with the code that manages runner leases and .lock files. Implement sibling-key eviction after a successful build, honoring the keep count, recent-use window, live leases, held locks, and the environment-variable opt-outs. Done means eligible old keys are removed, protected keys remain untouched, and eviction failures do not fail runner startup.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

Problem

~/.agent-device/apple-runner grows without bound. On a Mac that ran several agent-device versions and Xcode betas over three weeks it is 4.4 GB, and nothing in the product removes any of it.

Measured on 0.21.20 (main at 14e1bd7), macOS 27, Xcode 27.0 and 27.1:

Directory under ~/.agent-device/apple-runner/derived Size Contents
ios-simulator/cache-* 2.0 GB 13 keys, 125-225 MB each
macos/cache-* 1.3 GB 6 keys, 180-230 MB each
ios-device/cache-* 161 MB 1 key
tvos/, visionos/ 327 MB, 332 MB one un-keyed dev build each
top level Build, ModuleCache.noindex, ... and macos/{Build,...} ~440 MB one un-keyed dev build each
~/.agent-device/ios-runner/derived 119 MB left behind by the ios-runner to apple-runner rename

Cause

1. Runtime keys are never evicted (3.45 GB here, 20 keys).
resolveRunnerDerivedPath puts each build in derived/<platform>/cache-<hash>. The hash covers the runner source fingerprint, the Xcode and SDK versions and build numbers, the platform and device kind, and the build settings (comparableRunnerCacheMetadata drops only packageVersion and the manifest). Any runner source change or Xcode update therefore creates a new key, and the old key can never match again. The only cleanup that exists, cleanRunnerDerivedArtifacts, runs on the key being rebuilt.

The 13 iOS simulator keys here come from 9 distinct runner source fingerprints (package versions 0.20.10 through 0.21.20, including PR builds) across Xcode 26.6, 27.0 and 27.1. The oldest were last used three weeks ago and cannot match again. Last use is the mtime of .agent-device-runner-cache.json, which tryReuseExistingXctestrun rewrites on every reuse.

2. Most of each key is build scratch that reuse does not read (proposal, not fixed by the PR below).
For one iOS simulator key:

 5.3 MB  Build/Products                  <- xctestrun + runner bundles, all that reuse and launch need
55.6 MB  Build/Intermediates.noindex
76.0 MB  SDKExplicitPrecompiledModules
15.0 MB  ModuleCache.noindex
65.5 MB  Logs

A reused key is certified from Build/Products through the content manifest, and an invalid key is deleted and rebuilt from scratch, so the intermediates and module caches of a finished build should not be needed again (a live run against a trimmed key would confirm it). Trimming them after the manifest is written would cut about 97% of each key (155-225 MB to roughly 5 MB). Across the 20 keys above the Build/Products directories total 150 MB of 3.45 GB, so trimming would free about 3.3 GB without removing a single key.

3. pnpm build:package / prepack leave un-keyed builds in the same root (about 1.1 GB).
scripts/build-xcuitest-apple.sh writes to fixed paths: derived/ for iOS and derived/{macos,tvos,visionos}. build:package builds all four platforms, which is why tvOS and visionOS products exist on a machine that never drives those platforms. The daemon does not read these directories and they do not duplicate the keyed ones. pnpm clean:xcuitest removes them.

4. Aborted builds leave stubs. Keys containing only Logs/ and SourcePackages/ and orphaned cache-*.lock directories (tens of KB each).

No existing issue or PR covers this (searched issues and PRs for "derived data", "runner cache", "evict", "prune", "disk").

Required behavior (first PR)

After a successful runner build, evict sibling cache keys under the same platform folder, except:

  • the key just built;
  • the N most recently used keys (default 3, the new key included), by last-use time, and any key used within the last day;
  • any key a live runner lease points at (owner process live or unknown, or leased runner process still running);
  • any key whose .lock is held.

AGENT_DEVICE_IOS_RUNNER_CACHE_KEEP sets N; 0 turns eviction off. Eviction is skipped when AGENT_DEVICE_IOS_RUNNER_DERIVED_PATH is set, matching how automatic cleanup already treats that path. A failed eviction never fails the runner start.

On the machine above, N=3 frees about 2.1 GB (1.5 GB iOS simulator, 0.6 GB macOS) without touching any key a live runner uses.

Follow-ups

  • Trim build scratch from a key after its manifest is written (cause 2).
  • Make pnpm build:xcuitest:* write outside the daemon's keyed root, or have clean:xcuitest also cover ios-runner.
Langage dominant
TypeScript
Étoiles
4.9k
Forks
328
Merge moyen
12 h 19 min
PR mergées (30 j)
549

Préparer son environnement

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de callstack/agent-device

Toutes les issues de callstack/agent-device

Issues similaires

Plus d'issues TypeScript

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.