fix(browser): prevent stdio buffer blocking in Docker environments#27899
fix(browser): prevent stdio buffer blocking in Docker environments#27899stephenschoettler wants to merge 3 commits intoopenclaw:mainfrom
Conversation
Greptile SummaryThis PR contains two separate bug fixes:
Note: The PR title only mentions the browser fix, but includes the unrelated usage fix as well. According to the project's guidelines (CLAUDE.md), unrelated changes should typically be in separate PRs. Both fixes are valid, but bundling them may make the PR history harder to track. Confidence Score: 4/5
Last reviewed commit: 200f8c0 |
|
This pull request has been automatically marked as stale due to inactivity. |
7ef53df to
bd8bda0
Compare
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: bd8bda0c62
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
src/browser/chrome.ts
Outdated
|
|
||
| return spawn(exe.path, args, { | ||
| stdio: "pipe", | ||
| stdio: ["ignore", "ignore", "ignore"], |
There was a problem hiding this comment.
Keep Chrome stderr piped for startup failures
When Chrome exits before CDP comes up — for example because a container is missing shared libraries or still needs browser.noSandbox: true — this change removes the only actionable diagnostics we surface. launchOpenClawChrome still installs proc.stderr?.on("data") and includes stderrHint in the thrown error (src/browser/chrome.ts:379-413), but with fd 2 set to "ignore" proc.stderr is always null, so these failures now degrade to a generic timeout. Because stderr was already being drained, only stdout needed to stop piping to avoid the Docker backpressure issue.
Useful? React with 👍 / 👎.
bd8bda0 to
ef829e8
Compare
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: ef829e8ebf
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| // the tuple overload resolution varies across @types/node versions. | ||
| return spawn(exe.path, args, { | ||
| stdio: "pipe", | ||
| stdio: ["ignore", "ignore", "pipe"], |
There was a problem hiding this comment.
Ignore bootstrap stderr too to fix first-run Docker launches
When needsBootstrap is true (first run, or after the profile files are missing), launchOpenClawChrome() reuses spawnOnce() for the bootstrap process but does not attach a data listener until the later “real” launch. Because fd 2 is still pipe here, a noisy Chromium startup in containers can fill bootstrap.stderr and stall before Local State/Preferences are created, so the Docker deadlock this patch is fixing still reproduces on fresh profiles. Discarding or draining stderr for the bootstrap run would make the fix cover first-run launches as well.
Useful? React with 👍 / 👎.
Prevents crash when totals is undefined in byModel/byProvider/byAgent sort comparators. Fixes 'Cannot read properties of undefined (reading totalTokens)' crash that causes context overflow in active sessions.
… compat The stdio tuple overload resolves differently across @types/node versions (v20 vs v24/v25). Cast the spawn() result to ChildProcessWithoutNullStreams to ensure proc.stderr?.on/off type-checks regardless of installed @types/node.
ef829e8 to
036d09f
Compare
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 036d09fbb9
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| // the tuple overload resolution varies across @types/node versions. | ||
| return spawn(exe.path, args, { | ||
| stdio: "pipe", | ||
| stdio: ["ignore", "ignore", "pipe"], |
There was a problem hiding this comment.
Keep draining stderr after Chrome startup
When Chrome reaches CDP readiness we remove the only stderr listener (src/browser/chrome.ts:428-430), but this change still leaves fd 2 configured as "pipe". The comment at src/browser/chrome.ts:392-393 already notes that long-lived Chrome processes can emit periodic warnings; in Docker/root setups those warnings will now accumulate in the undrained pipe until it fills, at which point later writes block again. So this only fixes startup backpressure on stdout — long-running browser sessions are still vulnerable to the same stdio saturation issue once enough stderr is produced.
Useful? React with 👍 / 👎.
|
This pull request has been automatically marked as stale due to inactivity. |
Fixes browser automation failures in Docker by changing Chrome spawn configuration from
stdio: "pipe"tostdio: ["ignore", "ignore", "ignore"].Problem: When using
stdio: "pipe", Chrome's stdout/stderr buffers fill up (~64KB limit) and block the process, preventing CDP from becoming reachable within the timeout window.Solution: Discard Chrome's output instead of piping it. The codebase doesn't consume Chrome's stdout/stderr anyway, so there's no functional loss.
Result: CDP becomes reachable within ~500ms of Chrome startup in Docker.
Tested manually in Docker with Playwright Chromium on Debian 12.