Observed during Slock task #152 verification (unrelated PR, plan-reminders scope only — zero mcp references in diff).
Failure: mcp.spec.ts › MCP module completes stdio add... — clicking the install-progress button fails with element is not stable → element was detached from the DOM. The button re-renders as the install stage advances; under parallel e2e load the click lands across a re-render.
Flake evidence (both criteria): standalone run 2/2 passed; failing assertion targets the 扩展/MCP page (getByRole('main', { name: '扩展' })) with no overlap with the triggering PR's diff.
Same timing-sensitivity class as #2132 but a different test — filed separately to keep that issue's scope precise. Likely fix: make the click target stable across install-stage re-renders (key the button, or assert on a stable container action), or poll for the settled stage before clicking.
Observed during Slock task #152 verification (unrelated PR, plan-reminders scope only — zero mcp references in diff).
Failure:
mcp.spec.ts › MCP module completes stdio add...— clicking the install-progress button fails withelement is not stable→element was detached from the DOM. The button re-renders as the install stage advances; under parallel e2e load the click lands across a re-render.Flake evidence (both criteria): standalone run 2/2 passed; failing assertion targets the 扩展/MCP page (
getByRole('main', { name: '扩展' })) with no overlap with the triggering PR's diff.Same timing-sensitivity class as #2132 but a different test — filed separately to keep that issue's scope precise. Likely fix: make the click target stable across install-stage re-renders (key the button, or assert on a stable container action), or poll for the settled stage before clicking.