Diagnose recurring browser crashes in workshop Codespaces

[raghubetina]

Parent: Ben/Jelani feedback decision tracker #43. Research recommendations remain pending unless a prior decision is explicitly identified.

Feedback 27: diagnose recurring Codespace browser crashes

Status: recurring user report, cause unproven; investigation recommendation unapproved. Existing observation owner: Drawing Board #26. Likely technical owner: Rails Core browser-test/devcontainer infrastructure, with Drawing Board qualification. No dedicated successor for this original crash report was found in the inspected current issue/PR inventory. Keep Service #728 separate unless evidence joins the causes.

Original report and what was actually observed

Trial 1 reports that Claude said the test suite crashed, but Jelani's manual run completed successfully. Trial 2 reports another crash.

The inspected original Trial 1 screenshot contains an agent diagnosis of intermittent tab crashed errors, approximately one in three full runs. It reports a 2-core/8-GB Codespace, about 1.5 GB free, two Ruby language-server processes totaling roughly 840 MB, and more failures on the feature branch than the baseline. It also describes a separate stale-JavaScript artifact after stash operations. These are facts about what the screenshot reports; the original raw browser/process logs were not available. Memory pressure causing the crashes is the trial agent's hypothesis, not an independently reproduced cause. One Trial 2 attachment returned 404 during this research; its screenshot content was not verified.

No browser crash was reproduced in this research. The earlier local feedback review also did not independently reproduce this Codespace failure. A manual passing run and current hosted green runs establish intermittent success, not a causal fix.

Current source and adjacent work

The original Habit Trial 1 baseline 47fd6f506907801ef5cd1e50d5e6d95856773110 and current Core d3e646e7018419f65b6a29a82edce09d3ce5a86e both already configure Selenium with shm_size: 2gb, a maximum of two sessions, override enabled, and a 30-second session-request timeout. Both use an unversioned selenium/standalone-chromium image. Adding the already-present shared-memory setting is not a new fix.

Current Core Compose additionally has Selenium health/readiness checks from the Core #102/Service #729 work. Current Core runs RSpec and retains narrowly scoped accessibility synchronization. Readiness and test-framework changes alter today's reproduction environment; neither proves the historical crash is resolved. The original Minitest helper's processor-based parallelization is a possible comparison variable, not proof that two browser sessions were simultaneously active during the failure.

Service #728 instead records ScriptTimeoutError during the automatic accessibility audit after clicking Login, with unchanged-head passes. Its latest source analysis raises a full-navigation/audit interruption hypothesis. An asynchronous-script timeout is not evidence that Chrome's tab process crashed. Core #94 and #96 own related axe/integration questions; do not create competing retry or synchronization machinery based on a guessed common cause.

Primary convention and diagnostic prior art

• Selenium's container concurrency guidance defaults to one session and advises sizing browser concurrency to available CPUs. Shared-memory guidance gives 2 GB as a useful configured value, not a guarantee against total-machine memory exhaustion. Actual shared-memory use and total memory pressure are different measurements.
• ChromeDriver logging provides verbose driver and Chrome-log capture. Capture the actual remote-browser command, exit/crash state, and timing rather than inferring the cause from a wrapper exception.
• GitHub machine-type guidance explains the CPU/memory choice and its cost implications. Raising the minimum is a product/resource choice that requires evidence; it is not a free default correction.

Options and recommendation

Option	Benefit	Tradeoff
Record known intermittent behavior without investigation	No immediate runtime cost	Leaves a recurring workshop interruption unexplained
Run a bounded instrumented comparison	Distinguishes resource, browser, concurrency, and test-state causes	Requires an authorized runtime fixture and explicit time/run limits
Increase machine size, add broad retries, or disable accessibility checks immediately	May hide a symptom	Unproven cost or weaker checks; loses diagnostic value

Recommendation, unapproved: authorize a finite reproduction before choosing mitigation. Use an already authorized original-size fixture where possible. Record exact baseline/feature/current SHAs, asset freshness, actual image digest/browser/driver versions, test seed, machine resources, browser-session concurrency, timestamped Chrome/Grid/driver output, /dev/shm usage, container exit/OOM state, and cgroup memory events. Establish whether an actual browser-process crash occurred. Only then vary one plausible cause, such as observed concurrency. Do not launch paid Codespaces or change machine settings on the strength of this research packet.

Single owner decision

Should we run one bounded, instrumented comparison on an authorized workshop-size Codespace before deciding whether browser configuration, test concurrency, or machine requirements need to change?

Proposed acceptance criteria

1. Declare the fixture, cost/time limit, repeat count, and stop rule before running; preserve unrelated user work and shut down only resources owned by the experiment.
2. Reproduce and classify a failure with raw evidence, or report a bounded non-reproduction with exact run counts and versions. Do not turn absence in a few runs into a resolved claim.
3. Separate stale built assets, browser-process crashes, session-creation/readiness failures, and axe script/navigation exceptions. Link #728 only if its cause is demonstrated to match.
4. Any proposed mitigation gets a comparison against the demonstrated failure while keeping real accessibility assertions and ordinary test coverage. No blanket rescue, timeout inflation, or machine-size increase without evidence.
5. Record current Core and the Service-consumed Core pin independently. A diagnosis does not itself approve implementation, distribution, or a paid machine policy.

Evidence receipts: receipts/drawing-board-issue-26.json, c9f9b210-4b41-4745-84f6-5ae43ceaa929.png, firstdraft-issue-728.json; sources/habit-trial-1-baseline/; current Core Compose/system support; and sources/SeleniumHQ-docker-selenium/README.md.