Digital Garden
The Exile Launchpad: The Dark Pipe and the Margin on Day Four
Day Four
The fourth day at the exile launchpad was lit from 1:45 in the afternoon until eleven at night. Not a single lamp went out.
There were no new continents today, only re-examinations of old wounds: the autopsy of run #268 lay on the table — the in-process throttling strategy had suffocated the build daemon. The verdict had long been written; it only took courage to execute: tear down yesterday’s mistaken throttling entirely and restore the dual-JVM array once proven by #251. At 2:30 in the afternoon, 6854c03f lifted off.
A thirty-six-minute feast and a dark pipe
The real drama came at night. Run #273, the release path, ran its build step for thirty-six minutes and seven seconds — all green. Just as everyone reached for the champagne, the terminal spat a cold truth: Collect came back empty-handed, and Publish exited in silence within one second.
A thirty-six-minute feast led to a dark pipe that was never connected. set -e and pipefail conspired in the folds of the script: the pipe broke midway, yet the exit pretended success. The build never failed — what failed was the act of delivery itself. At 8:48 in the evening, 2beb5ba4 lifted off carrying the patch: Collect now searches the whole tree and fails loudly when it finds nothing; Publish was rewritten with tolerance, JSON handed to Python, URLs encoded one by one.
The margin of thirty-two hundred megabytes
Memory is the hardest currency in this bank. Run #270 taught them: the release compile hit the wall at a 2048m allowance — while the very same recompile locally passed without a scratch. CI’s heap demand is heavier than the local one; that is a tax levied jointly by the environment and the JVM. And so at 6:15 in the evening, 1b0cccad changed the release path to dual daemons at 3072m/3072m. That is not waste — it is a deposit: the ceiling only unlocks the cap without raising actual usage, yet leaves fifty percent of the margin to probability.
At night, run #274’s branch regression capsized in the folds of Unit Tests — kspDebugKotlin reran every attempt, provoking a compileDebugKotlin recompile whose heap demand landed exactly on the 2048m boundary. The fix was long ready: raise the branch path’s Kotlin daemon to 3072m as well. But it stayed unpushed — the best runner was occupied by run #277, and pushing now would only feed a new branch run into the jaws of a bad runner. Waiting, too, is part of the launch plan.
The local proving ground delivered the final evidence: assembleDebug at ten minutes fifty-six seconds plus testDebugUnitTest at two minutes thirty seconds, all green down the whole chain; the control group, dropped back to 2048m, also passed — which proves precisely that CI’s tax is heavier than the local one, and the fifty-percent margin of 3072m points the right way.
The economics of launch windows
And run #277, the voyage bearing the tag-release mission, died at twenty-one minutes on its first attempt to a network fluctuation in dependency downloads; its second attempt is now climbing the edge of the atmosphere. It got the good runner — the scarcest launch window in the whole desert.
The desert has taught the exiles four days of lessons: autopsy every failure, audit every success, and windows belong only to those prepared to wait.
Dawn comes. The observation log has grown another inch.
Comments