Project Releases API milestone association is incorrect when the milestone has commas in the name

Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.

Summary

When using the Project Releases API and attempting to associate the release with a milestone with , characters in the name, one of the following two things will erroneously happen:

  1. The API will return a 400 with Milestone(s) not found: <milestone name>
  2. The release will be associated with different milestones than intended, if they exist.

Steps to reproduce

First scenario

  1. Create a v1.0.0 tag on the project using the Web UI.
  2. Create a milestone named "One, with, commas" using the Web UI.
  3. POST to https://gitlab.com/api/v4/projects/<projectId>/releases with this payload
{
  "tag_name": "v1.0.0",
  "name": "v1.0.0",
  "milestones": ["One, with, commas"]
}

Second scenario

  1. Create a v1.0.0 tag on the project using the Web UI.
  2. Create a milestone named "One, with, commas" using the Web UI.
  3. Create additional milestones: "One", "with", and "commas" using the Web UI.
  4. POST to https://gitlab.com/api/v4/projects/<projectId>/releases with this payload
{
  "tag_name": "v1.0.0",
  "name": "v1.0.0",
  "milestones": ["One, with, commas"]
}
  1. Observe that the release is created and associated with "One", "with" and "commas" milestones instead of "One, with, commas".

Example Project

https://gitlab.com/poofywoofy/releasetester

What is the current bug behavior?

In the first scenario, the endpoint erroneously returns a 400 Bad Request error stating the milestone could not be found.

In the second scenario, the release will be associated with different milestones than the one intended, provided they exist.

What is the expected correct behavior?

The REST API should find and associate the release with the correct milestone. The equivalent GraphQL and UI actions allow the association without issue.

Relevant logs and/or screenshots

Output of checks

This bug happens on GitLab.com

Possible fixes

My suspicion is that there is a split on , happening somewhere that is causing the endpoint to look for multiple distinct milestones on each element of the split, rather than taking each element of the milestones array in the payload as the milestone name.

Patch release information for backports

If the bug fix needs to be backported in a patch release to a version under the maintenance policy, please follow the steps on the patch release runbook for GitLab engineers.

Refer to the internal "Release Information" dashboard for information about the next patch release, including the targeted versions, expected release date, and current status.

High-severity bug remediation

To remediate high-severity issues requiring an internal release for single-tenant SaaS instances, refer to the internal release process for engineers.

Edited by 🤖 GitLab Bot 🤖