Loading
feat: assign openOptions in Quick Chat state machine
Description
When re-triggering Quick Chat after using a quick fix code action (Fix with GitLab Duo), Quick Chat state machine context is not re-assigned properly keeping the outdated openOptions causing invalid state transitions.
Example:
Run Fix with Gitlab Duo and then trigger Quick Chat using shortcut.
- Expected: User prompt input shows up to enter new prompt
-
Current: Quick Chat is triggered without showing the user prompt input and proceeds to send the same prompt from
Fix with Gitlab Duo
Related Issues
Blocks #1854 (closed)
How has this been tested?
-
If src/browserorsrc/commonhas 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.
Manual Testing
- Set
"gitlab.featureFlags.fixWithDuoQuickChatCodeActions": truein settings.json - find some broken code, hover over and select "Fix with GitLab Duo"
- Once comment thread is created, press
option + cto open user prompt input - Enter prompt and proceed
Unit Tests
Screenshots (if appropriate)
| Before | After | |
|---|---|---|
| Quick Fix Action -> Regular Quick Chat |
![]() |
![]() |
| Regular Quick Chat -> Quick Fix Action | ![]() |
![]() |
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 Juhee Lee



