Yes, thanks for reminding. Do you mind if we do it in a follow-up?

What does this MR do and why?

Rather than relying on special handling of special "DUO_WORKFLOW_*" env variables in the Duo CLI's run_git_command this MR sets up the git environment in advance so that any git command which is run as a normal bash command works correctly.

Special considerations:

1. A git credential-helper approach does not work since Runners overwrite any git remote urls and injects the CI_JOB_TOKEN into those.
2. Instead we directly set up a URL with the oAuth token, which then does not get overwritten.
3. The old "DUO_WORKFLOW_*" variables are still used, for flows that still use run_git_command specifically right now.

References

Related to #586973

Screenshots or screen recordings

Before	After

How to set up and validate locally

1. Set up small issue. The goal is that the agent gets to pushing changes quickly.
2. Run "Generate MR with Duo" on it -> observe it still works and commands in the session look like in the "Before" screenshot.
3. Verify that changes are shown in result MR
4. In your local AI gateway change any occurence of run_git_command in duo_workflow_service/agent_platform/v1/flows/configs/developer.yml to run_command
5. Run "Generate MR with Duo" on it -> observe it still works and commands in the session look like in the "Before" screenshot
6. Verify that changes are shown in result MR

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.

@GitLabDuo _create_error_feedback method is called only from these two error code paths that I mentioned above

@romaneisner there are two bugs and I think both are unrelated to the changes in this MR

1. For my langsmith trace from yesterday: As I see in the fix_pipeline flow's definition, the routing for fix_pipeline_decide_approach depends on the Agent's final answer i.e. derived from an AgentComponent. if you checkout the agent's response, it decided to go for add_comment based on the information it had. There are no changes in this MR that can potentially impact AgentComponent's routing. Attached screenshot explains agent reasoning

I believe if want the agent to steer in a different direction, we need to make changes to the fix_pipeline flow specifically to the routing part to give it an exit when the Agent concludes it can't raise an MR with the fix or add comment since its working on default branch. This seems to be a genuine bug with fix_pipeline and can be recreated without this MR changes.

2. The one you ran yesterday for default branch pipeline failure: I re-generated the same scenario in my local and it was unusual to see agent going for tool_call even the prompt explicitly says to do nothing. I see the same behaviour in main branch too, i.e. without the changes in this MR. Here's the trace from main branch of gitlab-ai-gateway . I used Anthropic Sonnet 4.5 directly without vertex and the agent consistently created this incorrect tool_call. Attaching the SS from this run, you can see the same prompt as that in main branch.

   

we need to keep v1 and experimental in sync (with experimental being a superset of v1)

I planned to raise another MR to keep it consistent so that a single MR doesn't become too big.

Hey @rodrigo.tomonari I wasn't able to reproduce it even with the steps you mentioned but I can validate it with the unit tests, when I commented the rescue ActiveRecord::RecordInvalid, I got the exception ActiveRecord::RecordInvalid: Error adding importer user to Project members. Validation failed: User already exists in source.

Could you please review the MR as an SME?

Closing this thread as no longer applicable.

Surabhi Suman (ecca3b38) at 17 Mar 08:36

... and 1370 more commits

What does this MR do and why?

Introduces GetSavedViewWorkItemsTool, a new MCP GraphQL tool that queries namespace.workItems with filters extracted from a saved view. This tool maps saved view filter keys to GraphQL query variables and applies hierarchy scoping defaults.

This is the second of three MRs that break down !226663 (closed):

1. GetSavedViewTool (fetch saved view metadata) - !226995
2. This MR - GetSavedViewWorkItemsTool (fetch work items with filters)
3. Orchestrator service + tool registration

Key changes

• New Mcp::Tools::WorkItems::GetSavedViewWorkItemsTool class with a GetWorkItemsFull GraphQL query
• Filter mapping from saved view keys to GraphQL variables (assignees, labels, milestones, state, types, confidential, negated/union filters)
• Hierarchy scoping defaults (includeDescendants: true, excludeProjects: false, excludeGroupWorkItems: false)
• Pagination support via first/after params
• Work item response includes widgets (assignees, labels, milestone, dates, hierarchy)
• Comprehensive unit and integration tests

Supported filter mapping

How to set up and validate locally

Unit tests have been added. UI tests will be shared in the third MR.

References

• Part of #592440
• Split from !226663
• Implementation follows the MCP GraphQL Integration design document

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.

thanks @ngala, LGTM 🚀

thanks @ngala, LGTM 🚀

What does this MR do and why?

Introduces GetSavedViewTool, a new MCP GraphQL tool that queries namespace.savedViews to retrieve a saved view's metadata (name, description, filters, and sort configuration).

This is the first of three MRs that break down !226663 (closed):

1. This MR - GetSavedViewTool (fetch saved view metadata)
2. GetSavedViewWorkItemsTool (fetch work items with filters)
3. Orchestrator service + tool registration

Key changes

• New Mcp::Tools::WorkItems::GetSavedViewTool class that builds and executes a GetNamespaceSavedView GraphQL query
• Extracts the first saved view node from the response and returns it as structured content
• Returns an error if the saved view is not found or the user lacks access
• Comprehensive unit and integration tests

How to set up and validate locally

Unit tests have been added. UI tests will be shared in the third MR.

References

• Part of #592440
• Split from !226663
• Implementation follows the MCP GraphQL Integration design document

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.

Yeah I meant to put that comment on a different line to refer to process_result method. Sorry about that, thanks for addressing the comment!

@GitLabDuo the code path could either go for not tool_calls path or the errors path. In the next retry, the run method is called again and so the data gets refreshed. Can you think of a scenario when the context_dict could be stale?

@romaneisner @tmrrss could you please review this change? Original MR had to be reverted because of !4881 (comment 3159112842). I'm adding the changes again. I've tested this for developer (with git error), fix_pipeline (with pipeline failure in main branch) and DCR flows. Do lmk if there's any other scenario that I could be missing.

TIA

@GitLabDuo you didn't read the code correctly. this is the code

error_feedback = self._create_error_feedback(
                [feedback_message], [], attempts + 1, context
            )

            conversation_history_dict = self._conversation_history_key.to_nested_dict(
                [error_feedback]
            )
            result = merge_nested_dict(result, conversation_history_dict)
            result = merge_nested_dict(result, context_dict)

Error feedback is created where it updates the attempts and afterwards context_dict is updated so incremented value is preserved.

@GitLabDuo context_dict is updated after attempts are updated using merge_nested_dict(result, context_dict)

Surabhi Suman (41551b28) at 16 Mar 13:49