ReviewOS

home-lang/home

Corpus provisioning: pinned AWS CDK archive extraction fails

#714
Closed chris opened this 9 days ago ·
9 days ago

Refs #66 and #703.

After restoring the deleted worktree, the standard scripts/provision-corpus-deps.sh was run under the resource supervisor with pinned Bun 4982b91 first in PATH. Parent React provisioning succeeded. The frozen corpus install restored 2,898 packages but exited one: Fail extracting tarball for "aws-cdk-lib", version 2.148.0. The tracked manifests and lockfiles remain unchanged. This is an incomplete provisioning result, not full corpus readiness.

A separate read-only download of the exact registry tarball succeeded. The 22,311,838-byte archive matches the checked-in SHA-512 Pa0pyIHlhnsqtMkPJS3tnptYhoOSNDOgoFurNB4Qfa0vnAkjYQ+JKQkR1tNNr8+UtO9jUfXRklQgjEqlFlrgBA==. Python tar inspection reads all 5,945 regular entries (81,486,504 expanded bytes, maximum path length 124). No manual extraction into node_modules or lockfile changes were used. This establishes a valid reference archive, but does not identify the cause of Bun installation failure.

Evidence survives outside the worktree under the shared repository metadata directory bun-port-evidence/recovery-20260908: provision-corpus-deps.log, aws-cdk-lib-2.148.0.tgz, and aws-cdk-archive-audit.json. Pinned Bun SHA-256 remains 47a87c1dea30da59c2733cce80118ea59bd338c616c6378f1c7f55e5f2b92c87.

Investigate the native extraction/install path and preserve the first failed result. Verify the exact frozen corpus install completes without manually populating packages, changing locks, disabling checks, or accepting an eventual retry as the original outcome.

9 days ago

Native Home provisioning was attempted with the exact frozen corpus inputs and failed before extraction because of a separate prerelease-hash defect (#715). That failure is retained. The cause is now fixed in 6053c6c; production verification is building.

The next native provisioning result will be kept as a changed-code first outcome. If it succeeds, all 5,945 regular files installed for AWS CDK 2.148.0 will be compared byte-for-byte (SHA-256 per entry) with the already verified pinned archive. No archive was extracted manually into node_modules, no lockfiles were changed, and this issue remains open until the real installer/content check succeeds. Fresh recovery logs are also committed in 9391b1c, with prerelease diagnostics in 74cf29a.

9 days ago

Verified the production fix at 6053c6c. Build: 46/46 steps. Home executable SHA-256: fbc3cfe5af5e1c020e4aad2e6d4bae74584afbd87de970b1134e3ac653da9e15.

Native frozen prerelease regression passes all release/short-tag/long-tag/build-tag cases, with real dependency-removal rejection controls. Native create regression also passes. The original semver corpus reports 25 registered passes and zero failures.

The exact native frozen corpus provisioning succeeded. Both pinned lockfiles remain byte-identical. All 5,945 installed AWS CDK 2.148.0 regular files match the verified pinned tarball, with zero missing or different files. The subsequent corpus source audit retains 12,996 tracked entries: 12,990 identical regular files, five identical symlinks, and only the known expectations.txt metadata difference; no missing or mode differences.

Full logs, first failures, hashes, and the updated baseline are pushed in 65d0e916e. This completed the existing partially populated dependency tree; it is not a cold-install benchmark. The first pinned-Bun AWS extraction failure remains retained and is not replaced by Home's successful outcome.

This resolves the Home corpus provisioning blocker tracked here. The #715 hash fix allowed Home to reach its native extraction path and complete the actual pinned AWS install. This does not claim a repair to the separate pinned Bun executable.

Sign in to comment on this issue.