Port the Duo panel session-inbox MSW integration spec onto generated fixtures

Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.

• Close this issue

The session-inbox MSW integration spec was taken out of !251149 (merged) so that MR could ship without it. Porting it onto master's restructured harness ran into a blocker worth its own investigation, described below, and the inbox itself is covered by component specs in the meantime.

Why it was removed

ee/spec/frontend/msw_integration/handlers/ai_duo_panel.js moved to ee/spec/frontend/msw_integration/ai_duo_panel/test_support/api_handlers.js, and ee/spec/frontend/msw_integration/duo_agentic_chat/test_setup.js moved to ee/spec/frontend/msw_integration/ai_duo_panel/test_support/test_setup.js. Both moves landed via the refactor/consolidate-duo-chat-msw-handlers and fc-mr3-empty-spec-variants branches. On rebase this appears as a two-sided conflict that includes a deletion rather than a rename, so the old paths have to be taken from master and the change re-applied at the new location.

What the new scheme requires

api_handlers.js auto-maps fixture filenames to handlers via loadFixturesMap. A fixture named get_user_agent_flow_inbox.query.graphql.json under tmp/tests/frontend/fixtures-ee/graphql/ai_duo_panel/integration/ needs no handler code; the loader covers it. Generated fixtures also carry real schema __typename values. That matters here: the query selects both aliases through one in-file fragment, InboxConnection on DuoWorkflowConnection. Apollo silently drops fields whose fragment type condition cannot match, so a hand-written __typename that is wrong produces empty lists rather than an error. The old hand-rolled handler had this wrong at one point and claimed a type that is not in the schema.

One trap worth stating: defineFixtureVariants in ee/spec/frontend/msw_integration/fixture_variant_schema.js is consulted by ee/spec/frontend/msw_integration/work_items/handlers.js through getActiveVariant, but api_handlers.js never calls it. Registering a variant file for getUserAgentFlowInbox is inert unless that lookup is also wired into the Duo panel handler. Only add a variant file if a test needs a non-BASE case, and wire the lookup explicitly if so.

Work already parked locally

An it block was added to ee/spec/frontend/fixtures/ai_duo_panel_integration.rb in a nested describe with its own let_it_be records, so it does not rewrite get_user_agent_flows or shift row counts for specs that assert on that query. It seeds 21 awaiting-input sessions, 3 running sessions, and 1 chat-definition session. Statuses are set through the state machine rather than factory traits because only two of the three awaiting statuses have a trait.

The fixture data satisfies the tab logic: the decision tab paginates with needsDecisionFirst: 20, which requires more than 20 awaiting-input sessions; the All tab paginates on its own cursor; and no chat-definition session appears in either tab because the inbox sends type: non_foundational_chat_agents. The awaiting sessions sort behind the running ones deliberately, so the two connections' first 20 rows differ and a test cannot pass by reading the wrong alias.

The blocker

The generated fixture comes back with both aliases empty. It was isolated to licensed features in the fixture file's outer before block. In a standalone spec with stub_licensed_features(ai_catalog: true, ai_features: true, ai_workflows: true) the same query returns rows; dropping ai_workflows while keeping the rest returns zero.

Where the licence gate actually filters is not traced and not obvious. Ai::DuoWorkflows::WorkflowsFinder#base_query performs no ability check on the no-source path, it is just workflows.for_user(current_user.id). The next step is to find where ai_workflows is applied, then decide whether the fixture spec should stub it or whether the gate is a real bug.

Tests to preserve

The three cases the spec must cover:

1. The decision tab lists the rows from its own alias.
2. The All tab's rows appear after switching tabs.
3. The filtered-search bar renders, which also proves the inbox set its hasInitialWorkflows flag from the all alias.

Resolved: missing handler for getGitlabCreditsStatus

A stale fixture directory used to leave the renamed getGitlabCreditsStatus operation with no handler, aborting every suite in the directory before its first assertion with missing graphql handlers for operations: getGitlabCreditsStatus. Master's fixture generator now emits get_gitlab_credits_status.query.graphql.json, so regenerating with

bundle exec rspec ee/spec/frontend/fixtures/ai_duo_panel_integration.rb

fixes it. No handler stub is needed.

Runner note

These specs run with yarn jest:msw-integration. Plain yarn jest cannot run them: testPathIgnorePatterns excludes msw_integration and reports a misleading "No tests found, exiting with code 1" rather than a path error.

Verify with:

yarn jest:msw-integration ee/spec/frontend/msw_integration/ai_duo_panel

Parent issue: #616493 (closed)
Removed in: !251149 (merged)