Show agent sessions load errors inside the widget

What does this MR do and why?

When the agent sessions widget on a work item or merge request failed to load, it showed a page-level alert, and the widget itself rendered nothing. That also happened when there were zero sessions, so users couldn't tell a failed load from "no agent activity".

This MR follows the Pajamas alert guidelines:

  • Removes the createAlert calls from both widgets. Errors are still reported to Sentry.
  • On a query failure, the widget shell (title and container) stays visible. Inside the body it shows a contained GlAlert (variant="danger", not dismissible) with a contextual message: Failed to load agent sessions for this work item. or Failed to load agent sessions for this merge request. The alert clears after the next successful fetch (for example, when the work item widget's polling recovers). There is no retry action; it was considered and removed in favor of the existing refetch paths.
  • When the query succeeds with zero sessions, the widget shows a muted "No agent sessions" message using the CrudComponent empty slot.

The shell lives in the shared AgentSessionsList component, so the change adds three opt-in props there (hasError, showEmptyState, errorMessage). The pipeline sessions widget doesn't pass these props, so it behaves as before.

About the MR widget framework: the agent sessions MR widget isn't built on the MR widget framework (~/vue_merge_request_widget/components/widget/widget.vue). It's a standalone CrudComponent mounted directly in mr_widget_options.vue. Using the framework's built-in error state would mean rewriting the widget on top of the framework, which goes beyond a minimal fix. Both widgets use the shared in-widget alert instead.

References

Screenshots or screen recordings

Before After
Screenshot 2026-10-05 at 1.11.02 PM.png Screenshot 2026-10-05 at 1.19.34 PM.png
Screenshot 2026-10-05 at 1.11.09 PM.png Screenshot 2026-10-05 at 1.19.42 PM.png

How to set up and validate locally

For DAP/General Setup

Adding Sessions

  1. A: If you see no Sessions, you can trigger one that displays a Pipeline/Job by going to an Issue within your Duo enabled project and clicking the Generate MR with Duo button. It should trigger a new session that you can open up.
  2. B: You can also run the following query bundle exec rake "gitlab:duo_workflow:populate[50,20,1,<<YOUR_TEST_GROUP_PATH_HERE>>]" to create new agent sessions. Refresh the page. Make sure the group you are testing in has Duo assigned (see DAP setup above).

For this testing

  1. Sessions present: open the work item and the merge request that have sessions. The Sessions widget lists them as before.

  2. Empty state: open a work item and a merge request with no sessions. The widget shows No agent sessions instead of rendering nothing.

  3. Error state: the widget's GraphQL request goes to the same /api/graphql endpoint as the rest of the page, so devtools request blocking can't target it alone. Instead, make the sessions query fail with a temporary one-line edit (don't commit it):

    • Work item: in ee/app/assets/javascripts/work_items/components/agent_sessions/index.vue, in sessionsVariables, change id: this.workItemId, to id: 'not-a-valid-id',
    • Merge request: in ee/app/assets/javascripts/vue_merge_request_widget/widgets/agent_sessions/index.vue, change iid: String(this.mr.iid), to iid: Number(this.mr.iid),

    Reload the page. The widget title stays visible and the body shows a danger alert: Failed to load agent sessions for this work item. (or …for this merge request.). There's no page-level alert. Revert the edit with git checkout -- <file> when you're done.

Specs:

yarn jest ee/spec/frontend/ai/shared/widgets/agent_sessions_list_spec.js \
  ee/spec/frontend/vue_merge_request_widget/widgets/agent_sessions/index_spec.js \
  ee/spec/frontend/work_items/components/agent_sessions/index_spec.js

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

Edited by Emily Bauman

Merge request reports

Loading
Loading