test(canvas): e2e for desktop take-control reconnect + lease renewal (core#2332) #2335

Merged

claude-ceo-assistant merged 1 commits from feat/core-2332-display-reconnect-renewal-e2e into main 2026-06-06 05:20:42 +00:00

Conversation 0 Commits 1 Files Changed 1

+461

devops-engineer commented 2026-06-06 04:44:33 +00:00

Member

Copy Link

Copy Source

What

Adds the e2e coverage that core#2216 (desktop take-control reconnect + 300s lease-renewal) shipped without. core#2332 P0.7.

The happy path is already covered by canvas/e2e/staging-display.spec.ts (acquire -> noVNC WS upgrade -> first framebuffer frame). core#2216 layered two behaviours on top that had no e2e:

• (A) Reconnect re-acquires a FRESH token. On an unclean WS drop, DisplayTab runs connect(reacquire=true) -> reacquireSession() -> POST /display/control/acquire to mint a non-stale lease+token before reopening the socket -- otherwise the cached ~300s token can be past its expiry and the reconnect 401s (a dead session that looks like a reconnect).
• (B) The lease survives past 300s via the renewal cadence. The lock is a 300s lease with no server-side auto-renewal; DisplayTab runs a 120s setInterval that re-acquires as the same holder. The server's ON CONFLICT ... controlled_by = EXCLUDED.controlled_by upsert treats that as a lease extension, so expires_at moves forward and the user isn't kicked every ~5 min.

New spec: canvas/e2e/staging-display-reconnect.spec.ts

Sibling to staging-display.spec.ts -- identical gating (STAGING_DISPLAY_WORKSPACE_ID, skips loud, never fail-open), same same-origin-canvas WS auth model, same fail-closed "no flaky disposition" philosophy. Reuses the exact displayWebSocketConnection wire mechanics (subprotocols ["binary", "molecule-display-token.<token>"], #token= fragment parse, http->ws).

Test 1 -- reconnect re-acquires a FRESH token + framebuffer resumes
acquire -> open real noVNC WS (assert frame) -> drop -> re-acquire (same holder) and assert the new session_url carries a different signed token bound to a renewed expires_at (a reused token = the core#2216 401 bug) -> reopen WS on the fresh token and assert the framebuffer resumes (real frame, not a 1006/403 dead session).

Test 2 -- renewal pushes the lease past the original 300s window
Drives the renewal call the 120s timer fires (the same re-acquire POST) rather than sleeping 300s of wall-clock, then asserts:

• the renewal pushes expires_at strictly past the original 300s deadline;
• GET /display/control still reports a live holder on the renewed lease;
• a guard that RENEWAL_INTERVAL_MS (120s) < TTL (300s) (so a future change widening the interval past the TTL fails here).

What couldn't be exercised without a live desktop tenant

The literal "hold one WS open >300s of real wall-clock while the 120s timer renews underneath and assert the same socket never 1006s" variant needs >5 min of standing-desktop wall-clock per run and a funded standing desktop EC2. It's left as a precise TODO(core#2332) in the spec. The observable renewal cadence/effect (token freshness on reconnect + lease-extension past the original window) IS asserted deterministically.

Validation

• npx playwright test --config=playwright.staging.config.ts --list finds both new tests (Total: 4 tests in 3 files).
• tsc --noEmit on the spec (playwright+dom libs) -> exit 0; eslint -> exit 0. Parity-checked against the sibling spec under the same flags. (e2e/ is excluded from the main tsconfig; Playwright type-checks specs via its own transform.)

Gate / promote

Skips unless STAGING_DISPLAY_WORKSPACE_ID points at a standing desktop-capable staging workspace. Promote-to-required is a CTO call (standing desktop EC2 cost + >5 min cadence).

🤖 Generated with Claude Code

## What Adds the e2e coverage that core#2216 (desktop take-control reconnect + 300s lease-renewal) shipped without. core#2332 P0.7. The happy path is already covered by `canvas/e2e/staging-display.spec.ts` (acquire -> noVNC WS upgrade -> first framebuffer frame). core#2216 layered two behaviours on top that had **no** e2e: - **(A) Reconnect re-acquires a FRESH token.** On an unclean WS drop, `DisplayTab` runs `connect(reacquire=true)` -> `reacquireSession()` -> `POST /display/control/acquire` to mint a non-stale lease+token *before* reopening the socket -- otherwise the cached ~300s token can be past its expiry and the reconnect 401s (a dead session that looks like a reconnect). - **(B) The lease survives past 300s via the renewal cadence.** The lock is a 300s lease with **no** server-side auto-renewal; `DisplayTab` runs a 120s `setInterval` that re-acquires as the same holder. The server's `ON CONFLICT ... controlled_by = EXCLUDED.controlled_by` upsert treats that as a lease *extension*, so `expires_at` moves forward and the user isn't kicked every ~5 min. ## New spec: `canvas/e2e/staging-display-reconnect.spec.ts` Sibling to `staging-display.spec.ts` -- identical gating (`STAGING_DISPLAY_WORKSPACE_ID`, skips loud, **never fail-open**), same same-origin-canvas WS auth model, same fail-closed "no flaky disposition" philosophy. Reuses the exact `displayWebSocketConnection` wire mechanics (subprotocols `["binary", "molecule-display-token.<token>"]`, `#token=` fragment parse, http->ws). **Test 1 -- reconnect re-acquires a FRESH token + framebuffer resumes** acquire -> open real noVNC WS (assert frame) -> drop -> re-acquire (same holder) and assert the new `session_url` carries a **different** signed token bound to a renewed `expires_at` (a reused token = the core#2216 401 bug) -> reopen WS on the fresh token and assert the framebuffer **resumes** (real frame, not a 1006/403 dead session). **Test 2 -- renewal pushes the lease past the original 300s window** Drives the renewal **call** the 120s timer fires (the same re-acquire POST) rather than sleeping 300s of wall-clock, then asserts: - the renewal pushes `expires_at` strictly **past** the original 300s deadline; - `GET /display/control` still reports a live holder on the renewed lease; - a guard that `RENEWAL_INTERVAL_MS (120s) < TTL (300s)` (so a future change widening the interval past the TTL fails here). ## What couldn't be exercised without a live desktop tenant The literal "hold one WS open >300s of real wall-clock while the 120s timer renews underneath and assert the same socket never 1006s" variant needs >5 min of standing-desktop wall-clock per run and a funded standing desktop EC2. It's left as a precise `TODO(core#2332)` in the spec. The observable renewal cadence/effect (token freshness on reconnect + lease-extension past the original window) IS asserted deterministically. ## Validation - `npx playwright test --config=playwright.staging.config.ts --list` finds both new tests (Total: 4 tests in 3 files). - `tsc --noEmit` on the spec (playwright+dom libs) -> exit 0; `eslint` -> exit 0. Parity-checked against the sibling spec under the same flags. (`e2e/` is excluded from the main `tsconfig`; Playwright type-checks specs via its own transform.) ## Gate / promote Skips unless `STAGING_DISPLAY_WORKSPACE_ID` points at a standing desktop-capable staging workspace. **Promote-to-required is a CTO call** (standing desktop EC2 cost + >5 min cadence). 🤖 Generated with [Claude Code](https://claude.com/claude-code)

devops-engineer added 1 commit 2026-06-06 04:44:35 +00:00

test(canvas): e2e for desktop take-control reconnect + lease renewal (core#2332) ... 81aa23574c

core#2216 added two behaviours on top of the happy-path take-control flow that
staging-display.spec.ts already covers (acquire -> noVNC WS upgrade -> first
framebuffer frame), but neither had e2e coverage:

  (A) On an unclean WS drop the canvas re-acquires a FRESH control token before
      reconnecting (DisplayTab connect(reacquire=true) -> reacquireSession), so
      the ~300s cached token can't 401 the reconnect.
  (B) A 120s renewal timer re-acquires as the same holder, which the server's
      ON-CONFLICT upsert treats as a lease extension, keeping the 300s lease
      alive past its original window so the user isn't kicked every ~5 min.

New staging-display-reconnect.spec.ts (sibling to staging-display.spec.ts,
same gating/auth/fail-closed model):

  - reconnect test: acquire -> open real noVNC WS (frame) -> drop -> re-acquire
    and assert the new session_url carries a DIFFERENT signed token bound to a
    renewed expires_at -> reopen WS on the fresh token and assert the
    framebuffer RESUMES (real frame, not a 1006/403 dead session).
  - renewal test: drive the renewal CALL the 120s timer fires (the same
    re-acquire POST) and assert it pushes expires_at strictly past the original
    300s deadline, and that GET /display/control still reports a live holder on
    the renewed lease. We assert the observable renewal cadence/effect rather
    than sleeping 300s of wall-clock; a precise TODO notes the full real-time
    >300s-idle-WS variant is gated on a funded standing desktop EC2.

Gated on STAGING_DISPLAY_WORKSPACE_ID (skips loud otherwise, never fail-open),
identical to its sibling. Promote-to-required is a CTO call (standing desktop
EC2 cost + >5min cadence).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

devops-engineer requested review from agent-reviewer-cr2 2026-06-06 04:45:29 +00:00

devops-engineer requested review from agent-researcher 2026-06-06 04:45:30 +00:00

claude-ceo-assistant merged commit 1e0507ad9e into main 2026-06-06 05:20:42 +00:00

Sign in to join this conversation.

Reviewers

No Reviewers

agent-reviewer-cr2

agent-researcher

Labels

Clear labels

area/ci

CI/CD pipeline issues

do-not-auto-merge

Opt out of autonomous merge-queue merging

kind/infrastructure

Infrastructure-related issues

merge-queue

Ready for serialized Gitea merge queue

merge-queue-hold

Temporarily hold PR in merge queue

platform/go

Go platform test issues

release-blocker

Blocks the staging→main promotion / a release

release-test

security

test-label-sre

tier:high

High risk per dev-sop §SOP-6 — ceo only, 24h cooldown

tier:low

Low risk per dev-sop §SOP-6 — engineers/managers/ceo can approve

tier:medium

Medium risk per dev-sop §SOP-6 — managers/ceo can approve

triage-test

test

wip

Work in progress — do not auto-merge

No Label

Milestone

No items

No Milestone

Projects

Clear projects

No project

Assignees

Clear assignees

agent-dev-a agent-dev-b agent-pm agent-researcher agent-reviewer agent-reviewer-1 agent-reviewer-cr2 app-fe (Molecule AI · app-fe) app-lead (Molecule AI · app-lead) app-qa (Molecule AI · app-qa) claude-ceo-assistant claude-ci-reader claude-status-reaper core-be (Molecule AI · core-be) core-devops (Molecule AI · core-devops) core-fe (Molecule AI · core-fe) core-lead (Molecule AI · core-lead) core-offsec (Molecule AI · core-offsec) core-qa (Molecule AI · core-qa) core-security (Molecule AI · core-security) core-uiux (Molecule AI · core-uiux) cp-be (Molecule AI · cp-be) cp-lead (Molecule AI · cp-lead) cp-qa (Molecule AI · cp-qa) cp-security (Molecule AI · cp-security) cui (Zhanlin Cui) dev-lead (Molecule AI · dev-lead) devops-engineer documentation-specialist (Molecule AI · documentation-specialist) fullstack-engineer (Molecule AI · fullstack-engineer) hongming hongming-ceo-delegated hongming-codex-laptop hongming-kimi-laptop hongming-pc2 infra-lead (Molecule AI · infra-lead) infra-runtime-be (Molecule AI · infra-runtime-be) infra-sre (Molecule AI · infra-sre) integration-tester (Molecule AI · integration-tester) mc-drift-bot molecule-code-reviewer plugin-dev (Molecule AI · plugin-dev) pm publish-runtime-bot pypi-publisher (Molecule AI PyPI Publisher (RFC#596)) release-manager (Molecule AI · release-manager) sdk-dev (Molecule AI · sdk-dev) sdk-lead (Molecule AI · sdk-lead) sop-drift-bot sop-tier-bot (SOP Tier-Check Bot) technical-writer (Molecule AI · technical-writer) triage-operator (Molecule AI · triage-operator)

No Assignees

1 Participants

Notifications

Subscribe

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: molecule-ai/molecule-core#2335