v1.91.62.0 fix(cso): Rails verification fits two arm64 offline preparations (#3086)

* fix(cso): Rails verification fits two arm64 offline preparations

Offline Rails preparation compiles native gems in 6.8-8.5 min on 4-vCPU arm64 (3.3-3.5 min on amd64),
so a two-phase attempt outran the 900 s bound and its watchdogs' scheduled cleanup surfaced as
ISOLATION_FAILED. MAX_VERIFICATION_ATTEMPT_MS is now 1800 s, the longest comprehensive run budget;
attempts stay cut to the run's reporting deadline.

v1.91.58.0

* Take v1.91.62.0 (1.91.60.0 and 1.91.61.0 are claimed)
This commit is contained in:
Garry Tan authored and GitHub committed 2026-10-08 15:55:54 +00:00
1 parent 4dfd83bf8c
commit 9e9e674b1e
6 files changed
+40 -6

No files matched your search

+29
View File
@@ -1,5 +1,34 @@
# Changelog
## [1.91.62.0] - 2026-10-08
**A Rails repair can now finish verifying on arm64.**
On arm64, every Rails verification failed with `ISOLATION_FAILED`, reporting either "Exact reproduction cleanup failed" or "Attempt watchdog did not acknowledge execution-copy cleanup". Neither cleanup was broken. One attempt prepares the application twice, and an offline Rails preparation that compiles native gems takes 6.8 to 8.5 minutes on a 4-vCPU arm64 runner, against about 3.5 minutes on amd64. The 900-second attempt bound expired during the second preparation, the watchdogs cleaned up on schedule, and the helper reported that deadline as a cleanup failure.
### The numbers that matter
Measured on Ubicloud 4-vCPU runners with the staged Rails image from staging run 37735865870 and gstack 1d1ce39b4. Each figure is the start-to-kill time of one Docker group, taken from `docker events`.
| Rails verification step | amd64 | arm64 |
|---|---|---|
| Offline preparation (each of the two phases) | 3.3–3.5 min | 6.8–8.5 min |
| Phase observation (boot, controls, tests) | 8–10 s | 14–26 s |
| Where the 900 s attempt ended | finished in about 8 min | killed during the second preparation, 3 of 3 arm64 reference repairs |
| Attempt bound | 900 s | 1,800 s, still cut to the run's reporting deadline |
### What this means for you
Rails repairs on arm64 hosts, including Apple silicon Docker, can now reach `runtime_tested` and replay. Node, Bun and Python keep their 300-second attempt.
### Itemized changes
#### Fixed
- `MAX_VERIFICATION_ATTEMPT_MS`, the Rails attempt and replay bound, is now 1,800 seconds. That equals the longest comprehensive run budget, and each attempt is still cut to the run's reporting deadline. The attempt watchdog, the Docker verification executor and the assertion witness lifetime share this bound.
#### For contributors
- `test/cso-cli-lifecycle.test.ts` pins the new bound.
## [1.91.60.0] - 2026-10-08
**Windows setup finishes when the optional /cso helper fails to build, and it tells you when Smart App Control blocks gstack's binaries.**
+1 -1
View File
@@ -1 +1 @@
1.91.60.0
1.91.62.0
+1 -1
View File
@@ -1,4 +1,4 @@
# gstack digest v1.91.60.0 — regenerate/re-copy after upgrading gstack
# gstack digest v1.91.62.0 — regenerate/re-copy after upgrading gstack
Behavioral rules from gstack (https://github.com/garrytan/gstack), compressed
for agent hosts without a full skill install. The full skills add workflows,
+7 -2
View File
@@ -3,8 +3,13 @@ import { createHash } from 'node:crypto';
export const ABI = 3;
export const MAX_OUTPUT = 1024 * 1024;
/** Longest bounded verification attempt (a Rails attempt prepares two dependency trees); other stacks use 300 s. */
export const MAX_VERIFICATION_ATTEMPT_MS = 900_000;
/**
* Longest bounded verification attempt, used by Rails: one attempt prepares two dependency trees, and an
* offline Rails preparation that compiles native gems takes about 3.5 minutes on amd64 and 8.5 on arm64.
* It equals the longest comprehensive run budget, and every attempt is still cut to the run's reporting
* deadline. Other stacks use 300 s.
*/
export const MAX_VERIFICATION_ATTEMPT_MS = 1_800_000;
const UNSAFE_STRING_CONTROLS =
/[\x00-\x08\x0b\x0c\x0e-\x1f\x7f-\x9f\u061c\u200e\u200f\u2028-\u202e\u2066-\u2069]/u;
const UNSAFE_PROPERTY_CONTROLS = /[\x00-\x1f\x7f-\x9f\u061c\u200e\u200f\u2028-\u202e\u2066-\u2069]/u;
+1 -1
View File
@@ -1,6 +1,6 @@
{
"name": "gstack",
"version": "1.91.60",
"version": "1.91.62",
"description": "Garry's Stack — Claude Code skills + fast headless browser. One repo, one install, entire AI engineering workflow.",
"license": "MIT",
"type": "module",
+1 -1
View File
@@ -90,6 +90,6 @@ describe('bounded verification attempts', () => {
const { MAX_VERIFICATION_ATTEMPT_MS } = await import('../lib/cso/contracts');
for (const stack of ['node', 'bun', 'python']) expect(verificationAttemptMs(stack)).toBe(300_000);
expect(verificationAttemptMs('rails')).toBe(MAX_VERIFICATION_ATTEMPT_MS);
expect(MAX_VERIFICATION_ATTEMPT_MS).toBe(900_000);
expect(MAX_VERIFICATION_ATTEMPT_MS).toBe(1_800_000);
});
});