From 637975ecca9e810487e7fa1615dfa4dc7c77d358 Mon Sep 17 00:00:00 2001 From: qnbs <155236708+qnbs@users.noreply.github.com> Date: Wed, 19 Aug 2026 15:09:30 +0200 Subject: [PATCH 1/2] fix(cef): raise STARTUP_GRACE_MS to 15s after a real post-merge CI failure MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit main's own post-merge CEF Learning Harness run (triggered by PR #400's merge) failed with the exact "Cycle 1: no FFI boundary proof" symptom this file's own comment already documents as a known runner-speed- variance pattern (STARTUP_GRACE_MS was raised 4000->10000ms for the same reason before). Real, measured evidence for a plausible contributing factor this time: PR #400's -g flag on worldscript_host (apps/desktop-cef/CMakeLists.txt) grew the binary from 1.34MB to 6.33MB (4.7x). Cycles 2/3 in the same run always passed at the old 10s window — this only ever hits the cold first launch, consistent with slower first-time I/O on a larger binary under a loaded runner, not a logic regression. --- scripts/cef/run-launch-cycle-proof.mjs | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/scripts/cef/run-launch-cycle-proof.mjs b/scripts/cef/run-launch-cycle-proof.mjs index 5cc494916..65f813d81 100644 --- a/scripts/cef/run-launch-cycle-proof.mjs +++ b/scripts/cef/run-launch-cycle-proof.mjs @@ -54,7 +54,13 @@ const cyclesArg = cyclesArgIdx !== -1 ? process.argv[cyclesArgIdx + 1] : undefin const cycles = cyclesArgIdx === -1 ? 3 : Number(cyclesArg); // QNBS-v3: raised from 4000ms after two consecutive CI runs on identical code (byte-for-byte matching main, which had passed reliably before) showed the browser process alive but never reaching OnAfterCreated within the old window — runner-speed variance, not a code regression. -const STARTUP_GRACE_MS = 10000; +// QNBS-v3: raised again from 10000ms after the same "Cycle 1: no FFI boundary proof" symptom +// recurred on a main push right after PR #400 added -g to worldscript_host — real, measured +// evidence: the binary grew from 1.34MB to 6.33MB (target_compile_options in +// apps/desktop-cef/CMakeLists.txt), a plausible contributor to slower first-launch I/O on a +// loaded runner. Cycles 2/3 in the same run always passed at the old window — this only ever +// hits the cold first launch. +const STARTUP_GRACE_MS = 15000; const SHUTDOWN_GRACE_MS = 6000; // QNBS-v3: extra buffer after the main process exits — a renderer/GPU subprocess can take a moment longer to actually be reaped than its parent (docs/cef/knowledge/subprocess-and-shutdown.md's own "not instantaneous" finding applies to the whole tree, not just the browser process). const ORPHAN_CHECK_GRACE_MS = 3000; From 1b3a933fa5f05cd471317d408df74e90d3f3a67d Mon Sep 17 00:00:00 2001 From: qnbs <155236708+qnbs@users.noreply.github.com> Date: Wed, 19 Aug 2026 15:42:29 +0200 Subject: [PATCH 2/2] docs(cef): correct STARTUP_GRACE_MS comment scope (CodeAnt finding) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit CodeAnt finding on PR #401, verified real: the comment claimed the grace-period bump "only ever hits the cold first launch" (runCycle), but STARTUP_GRACE_MS is a shared constant also used by runCrashReportingProofCycle's own renderer-crash-detection timeout (line ~278). The bump widens that proof's failure-detection window too — harmless (strictly more lenient, same CI-runner-speed rationale applies to both), but the comment understated the actual scope. Updated to describe both consumers rather than splitting into a dedicated timeout, since there's no evidence the two need to differ. --- scripts/cef/run-launch-cycle-proof.mjs | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/scripts/cef/run-launch-cycle-proof.mjs b/scripts/cef/run-launch-cycle-proof.mjs index 65f813d81..ae43f749e 100644 --- a/scripts/cef/run-launch-cycle-proof.mjs +++ b/scripts/cef/run-launch-cycle-proof.mjs @@ -58,8 +58,12 @@ const cycles = cyclesArgIdx === -1 ? 3 : Number(cyclesArg); // recurred on a main push right after PR #400 added -g to worldscript_host — real, measured // evidence: the binary grew from 1.34MB to 6.33MB (target_compile_options in // apps/desktop-cef/CMakeLists.txt), a plausible contributor to slower first-launch I/O on a -// loaded runner. Cycles 2/3 in the same run always passed at the old window — this only ever -// hits the cold first launch. +// loaded runner. Cycles 2/3 in runCycle always passed at the old window — the actual observed +// failure only ever hit the cold first launch there. This constant is also read by +// runCrashReportingProofCycle's own renderer-crash-detection timeout below (line ~278) — a +// shared constant, not a runCycle-only one; that consumer's failure-detection window widens by +// the same 5s as a side effect, which is fine (strictly more lenient, same CI-runner-speed +// rationale applies), not a dedicated timeout since there's no evidence the two need to differ. const STARTUP_GRACE_MS = 15000; const SHUTDOWN_GRACE_MS = 6000; // QNBS-v3: extra buffer after the main process exits — a renderer/GPU subprocess can take a moment longer to actually be reaped than its parent (docs/cef/knowledge/subprocess-and-shutdown.md's own "not instantaneous" finding applies to the whole tree, not just the browser process).