Python repairs replay
gstack 1.91.36.0: /cso Python and Rails repairs now replay
every preparation hashed differentlytimestamped .pyc bytecode
0 differing filestwo preparations of the same Python app
A Python repair that /cso verified could never replay, because offline preparation wrote timestamped bytecode and every run hashed differently. Preparation now pins the source date, so two runs of the same app match file for file.
Rails replays ignore build logs
Rails replays stop tripping over RubyGems build logs
gem_make.out · mkmf.logname a random build directory, so the hash changed
logs left out of the hashcompiled extensions stay in it
Rails replays failed the same way. The build logs RubyGems writes record a random temporary directory. Those logs are now left out of the prepared app’s hash, while the compiled native extensions still count.
Rails verification fits its budget
A Rails verification gets 900 seconds
On a four-core host, a Rails attempt prepares the app twice, about four minutes each, and the watchdog stopped it at five. Rails attempts and replays now get fifteen minutes. Node and Bun keep five.
Killed attempts leave no scratch
A killed verification leaves nothing behind
supervisionpreparation-executionarchive-stagingarchive-materializationsverificationWhen the helper was killed mid-verification, the watchdog removed the containers, but the dead attempt’s scratch stayed in the run directory. Now resume and finish clear it, under the run lock.
Who this affects
For Python apps on requirements.txt or uv.lock, and Rails apps with native gems
CHANGELOG.md1.91.36.0 · What this means for youIf your Python app is locked with requirements or uv, or your Rails app uses native gems, verification now finishes and replays. These fixes were measured on amd64; arm64 and the full evaluator run on CI were unconfirmed at merge. The changelog covers the rest.
