apps/desktop/e2e/slash-command-menu.spec.ts:87 — offers commands only for the first token and keeps explicit Skill queries separate — fails intermittently on main.
Failing assertion
apps/desktop/e2e/slash-command-menu.spec.ts:106
await expect(inlineMenu.getByRole('group', { name: '命令' })).toHaveCount(0);
Error: expect(locator).toHaveCount(expected) failed
- unexpected value "1"
The composer holds explain / at that point. A slash that is not the first token must not open the command group — only the Skills group. Intermittently the command group is present and stays present for the whole polling window.
Reproduction
On main at 8925d4353, with no local changes:
npm --workspace @maka/desktop run build:with-deps
npm --workspace @maka/desktop exec -- playwright test --config e2e/playwright.config.ts e2e/slash-command-menu.spec.ts:87 --repeat-each=10 --workers=1
Two runs of 10 on that commit: 6 failures in 20. It also fails from a full-suite run, so it is not an artifact of --repeat-each.
Not caused by a recent change
Observed while verifying an unrelated UI branch. I checked out main itself and reproduced at the rate above, on a code path that branch does not touch, so this predates it. The CI failure that main showed earlier was a different spec (quote-selection.spec.ts) and is being fixed separately in #2946.
Why it matters
It is the only known flake left in the desktop e2e suite, so it will keep turning main and unrelated PRs red at roughly a 1-in-3 rate per run of this spec, which trains people to re-run rather than read failures.
Starting points
Whether this is a test-timing problem or a real product bug is still open — worth settling first:
- If the command group is genuinely rendered for
explain /, the defect is in whatever decides the inline menu's groups from the composer text, and the assertion is right to fail. - If it is a stale render from the preceding
composer.fill('seed session') / turn-completion step, the test needs to wait for the menu to settle for the new query rather than asserting on whatever is mounted at that instant.
A trace from a failing run is written to apps/desktop/e2e/test-results/slash-command-menu-offers--f3f8e-icit-Skill-queries-separate/trace.zip.
apps/desktop/e2e/slash-command-menu.spec.ts:87— offers commands only for the first token and keeps explicit Skill queries separate — fails intermittently onmain.Failing assertion
The composer holds
explain /at that point. A slash that is not the first token must not open the command group — only the Skills group. Intermittently the command group is present and stays present for the whole polling window.Reproduction
On
mainat8925d4353, with no local changes:Two runs of 10 on that commit: 6 failures in 20. It also fails from a full-suite run, so it is not an artifact of
--repeat-each.Not caused by a recent change
Observed while verifying an unrelated UI branch. I checked out
mainitself and reproduced at the rate above, on a code path that branch does not touch, so this predates it. The CI failure thatmainshowed earlier was a different spec (quote-selection.spec.ts) and is being fixed separately in #2946.Why it matters
It is the only known flake left in the desktop e2e suite, so it will keep turning
mainand unrelated PRs red at roughly a 1-in-3 rate per run of this spec, which trains people to re-run rather than read failures.Starting points
Whether this is a test-timing problem or a real product bug is still open — worth settling first:
explain /, the defect is in whatever decides the inline menu's groups from the composer text, and the assertion is right to fail.composer.fill('seed session')/ turn-completion step, the test needs to wait for the menu to settle for the new query rather than asserting on whatever is mounted at that instant.A trace from a failing run is written to
apps/desktop/e2e/test-results/slash-command-menu-offers--f3f8e-icit-Skill-queries-separate/trace.zip.