host tests: explicitly enter the right room in scripted-command test

[habdelra]

Summary

Acceptance | Commands tests: a scripted command can create a card, update it and show it flaked again on PR #4659 (CI run) — but the diagnostic landed in #4621 made the cause unambiguous.

The matrix-service / room.ts fix from #4621 is working. The roomResource for the test's mock_room_1 is fully populated:

"resourceForTestRoom": {
  "roomId": "mock_room_1",
  "hasMatrixRoom": true,
  "memberIds": ["@testuser:localhost", "@aibot:localhost"],
  "hasRoomState": true,
  "eventsCount": 10,
  "messagesCount": 2,
  "isProcessing": false
}

The problem: the panel rendered the wrong room.

"renderedRoomElements": [{ "roomId": "mock_room_0", ... }],
"serviceState": { "currentRoomId": "mock_room_0", ... },
"resourceForCurrentRoom": { "roomId": "mock_room_0", "messagesCount": 0 }

Why mock_room_0 wins the race

tests/helpers/mock-matrix/_server-state.ts createRoom auto-invites + joins @aibot:localhost for any roomId that doesn't match the auth-realm prefix. So the beforeEach createAndJoinRoom room (mock_room_0) qualifies as an AI session room just like the schedule-meeting room (mock_room_1) does. aiSessionRooms contains both.

enterRoomInitially (ai-assistant-panel-service.ts) prefers a persisted roomId from sessionStorage["currentRoomId"] over latestRoom. An earlier test in the same module (OpenAiAssistantRoomCommand opens the AI assistant room) clicks [data-test-open-ai-assistant-room-button] while the schedule-meeting click handler is still creating mock_room_1 in the background. If getRoomIds().pop() resolves before mock_room_1 exists, it returns mock_room_0 and that gets persisted — and mock_room_0 exists fresh in every test (counter resets), so the find succeeds.

Fix

Don't rely on the heuristic. Open the panel, then explicitly call aiAssistantPanelService.enterRoom(roomId) with the roomId we know we sent messages to, and waitFor a settled marker scoped to that specific room ([data-room-id="${roomId}"][data-room-settled]) so the test fails loudly if the right room never renders, instead of asserting on whichever Room happened to be in the DOM.

The diagnostic landed in #4621 stays in place — any future flake from a different cause is still fully attributable.

Test plan

• CI green on this branch
• No regression in test Bring in a demo from ember-animated #1 (OpenAiAssistantRoomCommand opens the AI assistant room) — that one still uses its own pattern and is untouched

🤖 Generated with Claude Code

[github-actions]

Preview deployments

• Host staging preview

• Host production preview

Host Test Results

    1 files  ±0      1 suites  ±0   2h 2m 47s ⏱️ - 1m 51s
2 565 tests ±0  2 550 ✅ ±0  15 💤 ±0  0 ❌ ±0 
2 584 runs  ±0  2 569 ✅ ±0  15 💤 ±0  0 ❌ ±0 

Results for commit 3470548. ± Comparison against earlier commit c1d9927.

Realm Server Test Results

    1 files  ±0      1 suites  ±0   17m 48s ⏱️ -9s
1 256 tests ±0  1 256 ✅ ±0  0 💤 ±0  0 ❌ ±0 
1 334 runs  ±0  1 334 ✅ ±0  0 💤 ±0  0 ❌ ±0 

Results for commit 3470548. ± Comparison against earlier commit c1d9927.

[Copilot]

Pull request overview

This PR fixes a flaky host acceptance test by removing reliance on the AI assistant panel’s “initial room selection” heuristic and instead explicitly entering the Matrix room that the test sends messages to.

Changes:

• After opening the AI assistant panel, explicitly call ai-assistant-panel-service.enterRoom(roomId) for the room created by the schedule-meeting flow.
• Tighten the test synchronization by waiting for a settled marker scoped to the expected room ([data-room-id="${roomId}"][data-room-settled]) rather than any room.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.