fix: prevent false chat availability in Web IDE without duo seat

Mohammed Osumahrequested to merge
557875-webide-respect-duo-settings into main

Description

Problem

Self-managed customers on Web IDE were seeing GitLab Duo Chat as available even when they lacked proper licensing/subscription sync. This created a poor user experience where:

  • Chat UI appeared functional but failed with confusing error messages
  • Users believed they had Duo access when they didn't
  • Error messages were inaccurate (e.g., "License not assigned" for Duo Core scenarios)

Root Cause: Web IDE doesn't use the language server, so ChatStateManager's availability check (chatState.engagedChecks.length === 0) was always returning true for the web ide, creating false positives.

Solution

  • Add Web IDE detection (vscode.env.uiKind === vscode.UIKind.Web)
  • Bypass ChatStateManager in Web IDE when LanguageServerWebIDE feature flag is disabled
  • Use direct chat availability checking (isDuoChatAvailable) that properly respects licensing/permissions
  • Maintain existing behaviour for desktop VS Code with language server

Changes

  • Modified activateChat() logic to conditionally use ChatStateManager
  • Added comprehensive unit tests covering Web IDE and feature flag combinations
  • Ensured proper subscription management for both code paths

Related Issues

Resolves https://gitlab.com/gitlab-org/gitlab/-/issues/557875

How has this been tested?

  1. Ensure GitLab Duo Core setting available to all users is not enabled (see screenshot below)

    Screenshot 2025-09-04 at 5.58.52 PM.png

  2. In your local gdk environment disable duo core for a user, by unassigning a duo seat for them

  3. Go on web ide example opening the project

  4. Ensure duo chat doesn't appear in the side panel of the web ide

  • If src/browser or src/common has been modified, please consider interoperability with the Web IDE. See Running the Extension in WebIDE.
  • Consider an end-to-end test for significant new features that aren't covered by integration tests.

Screenshots (if appropriate)

Screen Recording 2025-09-04 at 5.54.02 PM.mov

What CHANGELOG entry will this MR create?

  • fix: Bug fix fixes - a user-facing issue in production - included in changelog
  • feature: New feature - a user-facing change which adds functionality - included in changelog
  • BREAKING CHANGE: (fix or feature that would cause existing functionality to change) - should bump major version, mentioned in the changelog
  • None - other non-user-facing changes
Edited by Mohammed Osumah

Merge request reports