Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

DevOps Center tools query the unnamespaced data model only, failing on Managed Package orgs

Open
  • Is something wrong?
#44 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
68/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
typescript
Domain
devops, tooling

Research direction

Start with shared/orgType.ts and the existing branches in sfDevopsDetectConflict.ts and sfDevopsResolveConflict.ts, then inspect the six affected tools and their helpers: sfDevopsListProjects.ts, getProjects.ts, sfDevopsPromoteWorkItem.ts, getWorkItems.ts, and the checkout, commit, and pull-request entry points. Compare their standard queries with getWorkItemsMP.ts, getPipelineMP.ts, and getPipelineStagesMP.ts, then run test/getWorkItemsMP.test.ts. Done means all affected tools handle managed-package objects without breaking standard-org behavior.

Written by the indexing model from the issue text.

Description

Summary

Six of the GA devops toolset tools query the unnamespaced DevOps Center data model (WorkItem, DevopsProject) with no Managed Package fallback. On an org running the DevOps Center managed package (namespace sf_devops__), these tools fail immediately with sObject type 'WorkItem' is not supported.

This looks unintended for two reasons:

  1. The README points Managed Package users at these tools — it links to Merge Conflict Resolution with DevOps Center MCP Tools (Managed Package).
  2. The package already has the detection helper and uses it correctly in two tools. shared/orgType.ts exports isManagedPackageDevopsOrg(), and sfDevopsDetectConflict.ts / sfDevopsResolveConflict.ts branch on it to pick fetchWorkItemByNameMP() vs fetchWorkItemByName(). The other tools never call it.

The parallel MP implementations exist in the repo (getWorkItemsMP.ts, getPipelineMP.ts, getPipelineStagesMP.ts) and are covered by tests (test/getWorkItemsMP.test.ts) — they're simply not wired into most tool entry points.

Steps To Reproduce
  1. Authenticate against a production org with the DevOps Center managed package installed (namespace sf_devops__), with work items and an active pipeline.
  2. Configure the server scoped to the devops toolset: 
    {
  "mcpServers": {
    "salesforce-dx": {
      "command": "npx",
      "args": [
        "-y", "@salesforce/mcp@latest",
        "--orgs", "myOrgAlias",
        "--tools", "list_devops_center_projects,promote_devops_center_work_item"
      ]
    }
  }
}
  3. Invoke list_devops_center_projects with that org's alias.
  4. Invoke promote_devops_center_work_item with a valid work item name (e.g. WI-96271).
Expected result

Both tools operate against the managed package objects (sf_devops__Project__c, sf_devops__Work_Item__c, …), as detect_devops_center_merge_conflict already does on the same org.

Actual result

list_devops_center_projects:

Error fetching projects:
SELECT Id, Name, Description FROM DevopsProject
                                  ^
ERROR at Row:1:Column:35
sObject type 'DevopsProject' is not supported.

promote_devops_center_work_item:

Error fetching work items:
FROM WorkItem
     ^
ERROR at Row:16:Column:18
sObject type 'WorkItem' is not supported.

The managed package objects are present and queryable on the same org with the same authenticated user:

$ sf data query --query "SELECT Id FROM sf_devops__Work_Item__c LIMIT 5" --target-org myOrgAlias
Total number of records retrieved: 5.
Additional information

Root cause. The failing queries are unnamespaced and unconditional:

  • sfDevopsListProjects.ts → exec() inlines SELECT Id, Name, Description FROM DevopsProject (also duplicated in getProjects.ts::fetchProjects).
  • sfDevopsPromoteWorkItem.ts → exec() calls fetchWorkItemsByNames() from getWorkItems.ts, which queries FROM WorkItem.

Neither calls isManagedPackageDevopsOrg(). For contrast, sfDevopsDetectConflict.ts does exactly the right thing:

const isMP = await isManagedPackageDevopsOrg(connection);
if (isMP) {
  // Some orgs expose MP objects but store active DevOps Center data in standard WorkItem.
  // Prefer standard WorkItem when present; keep MP as fallback.
  const mpWorkItem = await fetchWorkItemByNameMP(connection, effectiveWorkItemName);
  ...
} else {
  workItem = await fetchWorkItemByName(connection, effectiveWorkItemName);
}

Affected tools (audit of packages/mcp-provider-devops/src/tools/, main):

Tool Queries unnamespaced Has managed package branch Works on managed package org
list_devops_center_projects yes no ❌
list_devops_center_work_items yes no ❌
promote_devops_center_work_item yes no ❌
checkout_devops_center_work_item yes no ❌
commit_devops_center_work_item yes no ❌
create_devops_center_pull_request yes no ❌
detect_devops_center_merge_conflict yes yes ✅
resolve_devops_center_merge_conflict yes yes ✅
Dominant language
No language data
Stars
1
Forks
1
No merged PRs in 30d

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from forcedotcom/mcp

All issues in forcedotcom/mcp

Similar issues

More DevOps issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.