issue:setup-remote builds invalid remote name for GitLab work-item ids

[mglaman]

Problem

issue:setup-remote fails for projects that migrated to GitLab work items (e.g. Canvas). Work-item ids are not Drupal.org issue nodes, so the node lookup returns no project machine name and the command builds a remote named -<id>, which git remote add rejects as an option:

$ drupalorg issue:setup-remote 3591806

In SetupIssueRemoteAction.php line 38:

  Failed to add remote -3591806: The command "'git' 'remote' 'add' '-3591806'
   'git@git.drupal.org:issue/-3591806.git'" failed.

  Error Output:
  ================
  error: unknown switch `3'
  usage: git remote add [<options>] <name> <url>

Work item 3591806 is a Canvas issue with an existing fork at git@git.drupal.org:issue/canvas-3591806.git and an open MR (project/canvas!1352). The fork is fine; only the project name resolution fails.

Root cause

GetIssueForkAction resolves the project exclusively through the Drupal.org node API:

if ($projectMachineName === null) {
    $issue = $this->client->getNode($nid);
    $projectMachineName = $issue->fieldProjectMachineName;
}
$remoteName = $projectMachineName . '-' . $nid;
$gitLabProjectPath = 'issue/' . $remoteName;

For a work-item id the node either does not exist or is an unrelated node that happens to share the id (3591806 resolves to a restrict_login_ip release node with no project field). $projectMachineName ends up empty, producing -3591806 and issue/-3591806.git.

Proposed fix

Fall back to GitLab when the node lookup yields no project machine name:

1. Resolve the work item via the GitLab API (/groups/project/work_items or the issue fork naming convention) to get the project machine name, or
2. Derive it from the current repository's origin remote (git@git.drupal.org:project/canvas.git → canvas), since the command already runs inside the project checkout.

Either way, guard against an empty machine name and fail with an explicit "could not resolve project for id" error instead of passing a --prefixed name to git.

Related: #337 handled work items in the skill docs; this is the same migration gap in the command itself.

Workaround

$ git remote add canvas-3591806 git@git.drupal.org:issue/canvas-3591806.git
$ git fetch canvas-3591806

[jdleonard]

(The rest of this comment was generated by AI (Claude Code Opus 5). I'm not realistically going to properly verify its conclusions, but at a distance it seems sensible and I judged this comment a net positive versus not posting it. Hope it's helpful!)

Confirming this on another migrated project — and with a variant that I think defeats the proposed fix.

Same root cause, drupalorg 0.10.3, project campaign, work item 3615648.

The collision node can have a populated field_project

The issue text assumes the colliding node yields no project machine name, and the proposed fix is to "guard against an empty machine name and fail with an explicit error". That guard would not have caught my case.

Work item 3615648 was created natively in GitLab after the migration, so it is not a Drupal.org node id at all. Node 3615648 on Drupal.org is a live, unrelated project_issue that happens to share the number:

$ curl -s https://www.drupal.org/api-d7/node/3615648.json | jq '{nid,title,type,project:.field_project.machine_name}'
{
  "nid": "3615648",
  "title": "sdx on shared hosting",
  "type": "project_issue",
  "project": "sdx"
}

So $projectMachineName is not empty — it is sdx. Nothing looks wrong, and the command proceeds confidently into the wrong project. An empty-string guard passes this straight through.

An explicitly qualified ref does not win

This is the part I found most surprising. Passing the project explicitly still routes through the node lookup and still resolves to sdx:

$ drupalorg issue:setup-remote campaign#3615648
$ git remote -v | grep 3615648
sdx-3615648	git@git.drupal.org:issue/sdx-3615648.git (fetch)
sdx-3615648	git@git.drupal.org:issue/sdx-3615648.git (push)

I told it the project. It asked Drupal.org anyway.

Blast radius is wider than issue:setup-remote

The same resolution path affects at least four more commands. Ordered by how dangerous I think they are:

issue:show — returns a different project's issue, in full, exit 0.

$ drupalorg issue:show 3615648 --format=llm
<drupal_context>
  <issue_id>3615648</issue_id>
  <title>sdx on shared hosting</title>
  <status>Fixed</status>
  <category>Support request</category>
  <project>sdx</project>
  ...

This is the one that worries me. It is not an error and not an empty record — it is a complete, plausible, richly populated issue belonging to someone else. An agent consuming --format=llm has no signal that it is reading the wrong thing.

mr:list — returns another project's merge requests, exit 0.

$ drupalorg mr:list 3615648 --format=llm
<drupal_context>
  <project_path>project/sdx</project_path>
  <merge_requests>
    <merge_request>
      <iid>1</iid>
      <title>Automated Project Update Bot fixes</title>
      <source_branch>project-update-bot-only</source_branch>
      ...

issue:fork with a bare nid — posts the slash command to the wrong project.

$ drupalorg issue:fork 3615648
Failed to post "/do:fork" to project/sdx#3615648: Client error: `POST https://git.drupalcode.org/api/v4/projects/project%2Fsdx/issues/3615648/notes` resulted in a `404 Not Found` response

This one is at least loud. drupalorg issue:fork campaign#3615648 works correctly, so issue:fork does honour the qualifier — which makes the setup-remote behaviour above look like an inconsistency rather than a design choice.

issue:checkout — same lookup, 404 on the wrong fork.

> GET /api-d7/node/3615648 HTTP/1.1
> GET /api/v4/projects/issue%2Fsdx-3615648 HTTP/1.1
< HTTP/1.1 404 Not Found

It fails before touching the working tree, so no damage.

There are two distinct node shapes, not one

Worth separating, because they fail differently:

Case	api-d7/node/<id>.json returns	Symptom
Migrated issue (3615635)	{"new_url":"https://git.drupalcode.org/project/campaign/-/work_items/3615635"}	empty record, status 0, epoch dates, exit 0
Post-migration work item (3615648)	a real node owned by an unrelated project	another project's data, exit 0

The first is a forwarding stub, HTTP 200, with no nid/title/field_project — deserializing it into an empty node object is what produces the status 0 / 1970-01-01 output. The second is not a lookup failure at all; it is a successful lookup of the wrong object.

The second case also gets steadily more likely over time: GitLab's iid counter for a migrated project keeps issuing numbers drawn from the same range as Drupal.org's global node-id sequence, so new work items will keep colliding with unrelated nodes.

Suggested amendment to the fix

Both listed options (resolve via GitLab, or derive from origin) look right to me. I would add two constraints:

1. An explicit project qualifier in the ref must short-circuit the node lookup entirely. campaign#<nid> should never consult api-d7.
2. Validity of the node cannot be inferred from a non-empty machine name. A new_url body should be followed (or treated as "this is a work item, go to GitLab"), and a node that resolves to a project other than the one implied by the ref or by origin should be treated as a collision and discarded — not trusted because it happens to be well-formed.