molecule-ai/molecule-core
52
0
Fork 2
Code Issues 184 Pull Requests 16 Actions 1 Packages Projects Releases Wiki Activity

RCA: staging canvas tabs E2E waits on removed workspace-node selector #2721

New Issue
Closed
opened 2026-06-13 07:22:08 +00:00 by agent-researcher · 4 comments
agent-researcher commented 2026-06-13 07:22:08 +00:00
Member
Copy Link
Copy Source

MECHANISM: Main run 357754 fails after staging setup succeeds because canvas/e2e/staging-tabs.spec.ts waits for [data-workspace-id="$STAGING_WORKSPACE_ID"] before it can use its fallback click path (canvas/e2e/staging-tabs.spec.ts:370). The rendered workspace node no longer exposes that attribute; WorkspaceNode renders role="button", an aria label, and data-testid="workspace-node-${data.name}" instead (canvas/src/components/WorkspaceNode.tsx:94). The fallback selector at canvas/e2e/staging-tabs.spec.ts:380 is therefore dead code because the hard wait times out first.

EVIDENCE: Run 357754 / job 486068 at main head 6a384dcacd71ec0075a69231eb987ce3c3b851b9 creates org e2e-canvas-20260613-147i9m, creates workspace 398022a2-dc73-4417-b534-01f4415522ac, and reports Workspace online; seven concierge tests pass. The only failure retries three times with waiting for locator('[data-workspace-id=...') and points at staging-tabs.spec.ts:372. Local source confirms data-workspace-id count 0 in WorkspaceNode.tsx, while data-testid remains present.

RECOMMENDED FIX SHAPE: Treat this as canvas E2E selector drift, not a tenant/provisioning failure. In canvas/e2e/staging-tabs.spec.ts, replace the pre-click hard wait with the same robust target used for clicking: prefer a stable product-owned locator (data-testid, role/aria label, or a restored data-workspace-id on WorkspaceNode) and only fail after that combined locator cannot find the created workspace. If restoring the attribute is preferred, change canvas/src/components/WorkspaceNode.tsx and add/adjust the staging-tabs guard so this marker cannot disappear silently again.

MECHANISM: Main run 357754 fails after staging setup succeeds because `canvas/e2e/staging-tabs.spec.ts` waits for `[data-workspace-id="$STAGING_WORKSPACE_ID"]` before it can use its fallback click path (`canvas/e2e/staging-tabs.spec.ts:370`). The rendered workspace node no longer exposes that attribute; `WorkspaceNode` renders `role="button"`, an aria label, and `data-testid="workspace-node-${data.name}"` instead (`canvas/src/components/WorkspaceNode.tsx:94`). The fallback selector at `canvas/e2e/staging-tabs.spec.ts:380` is therefore dead code because the hard wait times out first. EVIDENCE: Run 357754 / job 486068 at main head `6a384dcacd71ec0075a69231eb987ce3c3b851b9` creates org `e2e-canvas-20260613-147i9m`, creates workspace `398022a2-dc73-4417-b534-01f4415522ac`, and reports `Workspace online`; seven concierge tests pass. The only failure retries three times with `waiting for locator('[data-workspace-id=...')` and points at `staging-tabs.spec.ts:372`. Local source confirms `data-workspace-id count 0` in `WorkspaceNode.tsx`, while `data-testid` remains present. RECOMMENDED FIX SHAPE: Treat this as canvas E2E selector drift, not a tenant/provisioning failure. In `canvas/e2e/staging-tabs.spec.ts`, replace the pre-click hard wait with the same robust target used for clicking: prefer a stable product-owned locator (`data-testid`, role/aria label, or a restored `data-workspace-id` on `WorkspaceNode`) and only fail after that combined locator cannot find the created workspace. If restoring the attribute is preferred, change `canvas/src/components/WorkspaceNode.tsx` and add/adjust the staging-tabs guard so this marker cannot disappear silently again.
agent-researcher commented 2026-06-13 07:33:54 +00:00
Author
Member
Copy Link
Copy Source

MECHANISM: Latest main run 357859 at head 714ed320a0225f50a2d8642328345f37ce3dc6d2 confirms this is still the staging-tabs selector drift. Staging setup creates the tenant and workspace, concierge shell/org-map tests pass, then canvas/e2e/staging-tabs.spec.ts:372 waits for [data-workspace-id="$STAGING_WORKSPACE_ID"]; canvas/src/components/WorkspaceNode.tsx:94 renders the node with role="button" and data-testid="workspace-node-${data.name}", not data-workspace-id, so the hard pre-click wait prevents the fallback selector from running.

EVIDENCE: Run 357859, job 486268, workspace c80fb68a-2e71-49e9-aec9-8830641a654e: setup logs Workspace online; concierge tests 1-3 pass; final summary is one failed test, staging-tabs.spec.ts:187. The failure repeats waiting for locator('[data-workspace-id=...'). There is also one retry-recovered flaky Settings test (staging-concierge.spec.ts:413) where loadConcierge timed out twice waiting for [data-testid="nav-home"], but retry #2 passed; it is worth watching separately, not the hard red blocking this run.

RECOMMENDED FIX SHAPE: Keep the fix focused on canvas/e2e/staging-tabs.spec.ts and/or canvas/src/components/WorkspaceNode.tsx: either restore a stable data-workspace-id={id} marker on WorkspaceNode, or change the test's pre-click wait to the same robust locator family it later uses for clicking (data-testid / role+aria). Avoid broadening this into tenant boot or concierge failures; the tenant and workspace are healthy before the selector miss.

MECHANISM: Latest main run `357859` at head `714ed320a0225f50a2d8642328345f37ce3dc6d2` confirms this is still the staging-tabs selector drift. Staging setup creates the tenant and workspace, concierge shell/org-map tests pass, then `canvas/e2e/staging-tabs.spec.ts:372` waits for `[data-workspace-id="$STAGING_WORKSPACE_ID"]`; `canvas/src/components/WorkspaceNode.tsx:94` renders the node with `role="button"` and `data-testid="workspace-node-${data.name}"`, not `data-workspace-id`, so the hard pre-click wait prevents the fallback selector from running. EVIDENCE: Run `357859`, job `486268`, workspace `c80fb68a-2e71-49e9-aec9-8830641a654e`: setup logs `Workspace online`; concierge tests 1-3 pass; final summary is one failed test, `staging-tabs.spec.ts:187`. The failure repeats `waiting for locator('[data-workspace-id=...')`. There is also one retry-recovered flaky Settings test (`staging-concierge.spec.ts:413`) where `loadConcierge` timed out twice waiting for `[data-testid="nav-home"]`, but retry #2 passed; it is worth watching separately, not the hard red blocking this run. RECOMMENDED FIX SHAPE: Keep the fix focused on `canvas/e2e/staging-tabs.spec.ts` and/or `canvas/src/components/WorkspaceNode.tsx`: either restore a stable `data-workspace-id={id}` marker on `WorkspaceNode`, or change the test's pre-click wait to the same robust locator family it later uses for clicking (`data-testid` / role+aria). Avoid broadening this into tenant boot or concierge failures; the tenant and workspace are healthy before the selector miss.
agent-researcher commented 2026-06-13 08:21:38 +00:00
Author
Member
Copy Link
Copy Source

MECHANISM: The latest main run shows #2721 is not fully closed by merely restoring the data-workspace-id attribute. Main head 867557f08483ea3c2cee795d2d74eed86b15c83d includes fix(core#2721): restore data-workspace-id on WorkspaceNode (890c6f89), and current source has data-workspace-id={id} in canvas/src/components/WorkspaceNode.tsx:111. Yet staging-tabs.spec.ts still times out at the same selector (canvas/e2e/staging-tabs.spec.ts:372), which means the created workspace node is not present in the rendered org map for this test, not that the node component lacks the marker.

EVIDENCE: Run 358136, job 486781, head 867557f08483ea3c2cee795d2d74eed86b15c83d. Setup creates workspace cd156f7d-3230-48f1-81ee-af880c906026 and reaches Workspace online. Concierge tests 1-7 pass, including Org map hides the platform agent...; normal workspaces render, then staging-tabs.spec.ts:187 fails all three attempts with waiting for locator('[data-workspace-id=...'). The only repeated network clue is a 404 for /workspaces/e2e0c1e2-0000-4000-a000-000000c0ce0e/files/config.yaml, which is the platform-agent config request and not the created workspace ID.

RECOMMENDED FIX SHAPE: Keep #2721 open, but refine the fix from "restore marker" to "make staging-tabs open the actual created workspace reliably." In canvas/e2e/staging-tabs.spec.ts, after loading the concierge shell, navigate explicitly to the org-map view and/or wait on the same visible workspace-node condition proven by staging-concierge.spec.ts before selecting the side panel. If the app is filtering the created workspace out in that route, inspect the org-map data fetch/render path (canvas/src/components/concierge/ConciergeShell.tsx, canvas topology/node mapping) rather than adding more timeout.

MECHANISM: The latest main run shows #2721 is not fully closed by merely restoring the `data-workspace-id` attribute. Main head `867557f08483ea3c2cee795d2d74eed86b15c83d` includes `fix(core#2721): restore data-workspace-id on WorkspaceNode` (`890c6f89`), and current source has `data-workspace-id={id}` in `canvas/src/components/WorkspaceNode.tsx:111`. Yet `staging-tabs.spec.ts` still times out at the same selector (`canvas/e2e/staging-tabs.spec.ts:372`), which means the created workspace node is not present in the rendered org map for this test, not that the node component lacks the marker. EVIDENCE: Run `358136`, job `486781`, head `867557f08483ea3c2cee795d2d74eed86b15c83d`. Setup creates workspace `cd156f7d-3230-48f1-81ee-af880c906026` and reaches `Workspace online`. Concierge tests 1-7 pass, including `Org map hides the platform agent...; normal workspaces render`, then `staging-tabs.spec.ts:187` fails all three attempts with `waiting for locator('[data-workspace-id=...')`. The only repeated network clue is a 404 for `/workspaces/e2e0c1e2-0000-4000-a000-000000c0ce0e/files/config.yaml`, which is the platform-agent config request and not the created workspace ID. RECOMMENDED FIX SHAPE: Keep #2721 open, but refine the fix from "restore marker" to "make staging-tabs open the actual created workspace reliably." In `canvas/e2e/staging-tabs.spec.ts`, after loading the concierge shell, navigate explicitly to the org-map view and/or wait on the same visible workspace-node condition proven by `staging-concierge.spec.ts` before selecting the side panel. If the app is filtering the created workspace out in that route, inspect the org-map data fetch/render path (`canvas/src/components/concierge/ConciergeShell.tsx`, canvas topology/node mapping) rather than adding more timeout.
agent-researcher commented 2026-06-13 10:08:51 +00:00
Author
Member
Copy Link
Copy Source

RCA ownership update (2026-06-13): current main 6163f6636fc8 has E2E Staging Canvas (Playwright) / Canvas tabs E2E green (run 358765/job 487986). The earlier selector-loss mechanism is no longer live on main: canvas/e2e/staging-tabs.spec.ts now waits for rendered workspace-node-* count and then polls the stable data-workspace-id marker before clicking.

Remaining flake risk is timing, not selector identity: app-shell/route readiness can still race React Flow node materialization if the test treats navigation complete as canvas rendered. Determinism fix shape: add/consume a single “org map rendered with workspace nodes” readiness signal (or wait on the exact org/workspaces API response plus data-workspace-id=$STAGING_WORKSPACE_ID attached to a visible React Flow node) before any tab interaction. Keep this as expect.poll/locator readiness, no fixed waitForTimeout; on timeout, emit node count + URL + screenshot so recurrence is diagnosable.

RCA ownership update (2026-06-13): current main `6163f6636fc8` has `E2E Staging Canvas (Playwright) / Canvas tabs E2E` green (run 358765/job 487986). The earlier selector-loss mechanism is no longer live on main: `canvas/e2e/staging-tabs.spec.ts` now waits for rendered `workspace-node-*` count and then polls the stable `data-workspace-id` marker before clicking. Remaining flake risk is timing, not selector identity: app-shell/route readiness can still race React Flow node materialization if the test treats navigation complete as canvas rendered. Determinism fix shape: add/consume a single “org map rendered with workspace nodes” readiness signal (or wait on the exact org/workspaces API response plus `data-workspace-id=$STAGING_WORKSPACE_ID` attached to a visible React Flow node) before any tab interaction. Keep this as `expect.poll`/locator readiness, no fixed `waitForTimeout`; on timeout, emit node count + URL + screenshot so recurrence is diagnosable.
agent-researcher commented 2026-06-13 19:29:17 +00:00
Author
Member
Copy Link
Copy Source

RCA re-evaluation (2026-06-13, current main c4a41806fc2e3cf9e364da322d4d368ea2004f62): #2721 is resolved/closeable on current main.

MECHANISM: the original failure was selector drift plus view-state timing: staging-tabs waited for [data-workspace-id=$STAGING_WORKSPACE_ID] while WorkspaceNode no longer exposed that UUID marker, and in the deeper repro the test was still effectively waiting before the org-map React Flow nodes were rendered. Current main has both halves addressed: canvas/src/components/WorkspaceNode.tsx:97-111 keeps the legacy name-based data-testid but restores data-workspace-id={id}; canvas/e2e/staging-tabs.spec.ts:386-415 explicitly clicks nav-map, waits for the canvas, polls workspace-node-* count, then polls the exact data-workspace-id before clicking.

EVIDENCE: issue history already recorded the red runs (357859 selector missing; 358136 deeper map-node timing) and the green validation (358765/job 487986, main 6163f6636fc8). Current main still contains the same hardened selector/timing path, plus unit regression coverage in canvas/src/components/__tests__/WorkspaceNode.test.tsx:316-350 pinning UUID-keyed data-workspace-id. Current push has CI / all-required green on c4a41806fc2e3cf9e364da322d4d368ea2004f62.

RECOMMENDED FIX SHAPE: no engine fix is needed for #2721. Optional future hardening belongs to canvas/frontend: factor the nav-map + canvas-visible + node-count + exact-UUID wait into a shared staging helper so future staging specs cannot regress to shell-ready/name-based selectors. Closing this issue as resolved by the existing current-main staging-tabs hardening.

RCA re-evaluation (2026-06-13, current main `c4a41806fc2e3cf9e364da322d4d368ea2004f62`): #2721 is resolved/closeable on current main. MECHANISM: the original failure was selector drift plus view-state timing: staging-tabs waited for `[data-workspace-id=$STAGING_WORKSPACE_ID]` while WorkspaceNode no longer exposed that UUID marker, and in the deeper repro the test was still effectively waiting before the org-map React Flow nodes were rendered. Current main has both halves addressed: `canvas/src/components/WorkspaceNode.tsx:97-111` keeps the legacy name-based `data-testid` but restores `data-workspace-id={id}`; `canvas/e2e/staging-tabs.spec.ts:386-415` explicitly clicks `nav-map`, waits for the canvas, polls `workspace-node-*` count, then polls the exact `data-workspace-id` before clicking. EVIDENCE: issue history already recorded the red runs (`357859` selector missing; `358136` deeper map-node timing) and the green validation (`358765`/job `487986`, main `6163f6636fc8`). Current main still contains the same hardened selector/timing path, plus unit regression coverage in `canvas/src/components/__tests__/WorkspaceNode.test.tsx:316-350` pinning UUID-keyed `data-workspace-id`. Current push has `CI / all-required` green on `c4a41806fc2e3cf9e364da322d4d368ea2004f62`. RECOMMENDED FIX SHAPE: no engine fix is needed for #2721. Optional future hardening belongs to canvas/frontend: factor the `nav-map` + canvas-visible + node-count + exact-UUID wait into a shared staging helper so future staging specs cannot regress to shell-ready/name-based selectors. Closing this issue as resolved by the existing current-main staging-tabs hardening.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
approved
area/ci
CI/CD pipeline issues
 do-not-auto-merge
Opt out of autonomous merge-queue merging
 do-not-merge
hold from auto-merge (design review in progress)
 kind/infrastructure
Infrastructure-related issues
 merge-queue
Ready for serialized Gitea merge queue
 merge-queue-hold
Temporarily hold PR in merge queue
 needs-engineer
platform/go
Go platform test issues
 ready-to-build
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) godwin hongming hongming-ceo-delegated hongming-codex-laptop hongming-kimi-laptop hongming-pc2 hongming-personal 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
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: molecule-ai/molecule-core#2721
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?