Charon/docs/plans/phase_2_interruption_analysis.md

post_title, author1, post_slug, microsoft_alias, featured_image, categories, tags, ai_note, summary, post_date

post_title	author1	post_slug	microsoft_alias	featured_image	categories	tags	ai_note	summary	post_date
Phase 2 Test Interruption Analysis	Charon Team	phase-2-test-interruption-analysis	charon-team	https://wikid82.github.io/charon/assets/images/featured/charon.png	testing	playwright e2e phase-2 diagnostics	true	Analysis of Phase 2 Playwright interruptions, with root cause hypotheses and recommended diagnostics to stabilize execution.	2026-02-09

1. Introduction

This analysis investigates Phase 2 Playwright test interruptions that surface as exit code 130 and errors such as "Target page, context or browser has been closed" or "Test ended." The focus is on the setup/teardown flow, storage state usage, and security-related dependencies that can affect browser lifecycles.

2. Research Findings

2.1 Setup and Auth Storage State Flow

• Phase 1 authentication is performed in tests/auth.setup.ts using the Playwright request context, with storage state persisted to the path defined by tests/constants.ts.
• The auth setup validates cookie domain alignment with baseURL and writes the storage state to playwright/.auth/user.json, which Phase 2 uses.
• Global setup in tests/global-setup.ts performs preflight health checks, optional emergency security reset, and cleanup. It does not explicitly close browsers, but it can terminate the process if the emergency token is invalid.

2.2 Playwright Project Dependencies and Scheduling

• playwright.config.js declares projects for setup, security-tests, security-teardown, and the browser projects.
• When PLAYWRIGHT_SKIP_SECURITY_DEPS is set (default), browser projects depend only on setup, but security-teardown remains a standalone project and can still run during the same invocation.
• Fully parallel execution is enabled, so independent projects may run in parallel unless constrained.

2.3 Security Teardown Behavior

• tests/security-teardown.setup.ts uses an authenticated API request context and enforces a specific security state: Cerberus enabled, modules enabled, and admin whitelist configured.
• This teardown is documented as a post-security-test action, but it is not guarded from running alongside non-security browser tests.

2.4 Test-Level Browser/Context Closure

• No Phase 2 core/settings/tasks tests explicitly close the shared browser.
• A direct context.close() exists in tests/monitoring/real-time-logs.spec.ts, but it is scoped to a context created in beforeAll and should not affect other tests.

3. Root Cause Hypotheses (Ranked)

H1: Security Teardown Runs Concurrently and Alters State Mid-Run

Because security-teardown is configured as a standalone project, it can run in parallel when security dependencies are skipped. Its API calls modify security settings and admin whitelist configuration. If this overlaps with Phase 2 navigation or API-driven setup, it can lead to transient 401/403 responses, blocked routes, or reload events. The resulting timeouts can cause Playwright to end tests early, which produces "Test ended" and "Target page, context or browser has been closed" errors.

H2: Storage State Domain Mismatch or Invalid State

auth.setup.ts writes storage state for the baseURL domain. If Phase 2 runs with a different PLAYWRIGHT_BASE_URL host (for example, localhost vs 127.0.0.1), cookies may not be sent, leading to authentication failures. Tests that assume an authenticated session can then hang in navigation or UI assertions, eventually triggering test end and context closure errors.

H3: Global Setup Emergency Reset Leaves Partial State

Global setup performs an emergency reset and a post-auth reset if storage state exists. If the emergency server or token validation is inconsistent, the reset may partially apply, leaving security modules enabled without the expected whitelist. This can block subsequent API calls and surface as navigation timeouts, especially early in Phase 2.

H4: Environment Instability or Resource Pressure

If the Docker container becomes unresponsive, navigation requests can fail or hang, which can cascade into test termination. No direct evidence is present in this review, but the symptoms are consistent with sudden page closures after a few tests.

4. Recommendations for Next Steps

• Confirm whether security-teardown is executing during Phase 2 runs and whether it overlaps with browser projects. If it does, isolate it to only run when security-tests are executed or after them.
• Validate storage state consistency by confirming Phase 2 uses the same PLAYWRIGHT_BASE_URL host as Phase 1 authentication. Align to a single host (127.0.0.1 or localhost) and keep it consistent across setup and tests.
• Capture Playwright project scheduling output and test order to confirm whether any teardown is running concurrently with Phase 2 suites.
• Add a lightweight health check in Phase 2 suites (or in the base fixture) to detect server unresponsiveness early and surface actionable failures instead of page-closed errors.

5. Acceptance Criteria

• Phase 2 suites (core, settings, tasks) run to completion without premature browser/context closure errors.
• No occurrences of "page.goto: Target page, context or browser has been closed" or "page.goto: Test ended" in Phase 2 runs.
• Project scheduling confirms security-teardown does not run concurrently with non-security browser projects when security dependencies are skipped.