API created issue do not get assigned to specified milestone

Summary

When creating an Issue using the API (v4) as an authenticated user, the milestone_id is ommitted and the issue is not assigned to the milestone

Steps to reproduce

curl --request POST --header "PRIVATE-TOKEN: PlainTextToken" "https://gitlab.com/api/v4/projects/6472898/issues?title=Test%20Issues&milestone_id=1"

Example Project

Reproduced in https://gitlab.com/deau21/test-milestone-issue

What is the current bug behavior?

Issue gets created but not assigned to the specified milestone.

What is the expected correct behavior?

Issue gets created and is assigned to the specified milestone.

Output of checks

This bug happens on Gitlab CE 10.8.0 (55e4a0b3) AND on GitLab.com

Results of GitLab environment info

Expand for output related to GitLab environment info

(For installations with omnibus-gitlab package run and paste the output of:
sudo gitlab-rake gitlab:env:info)
docker exec -it gitlab gitlab-rake gitlab:env:info
System information
System:
Current User:	git
Using RVM:	no
Ruby Version:	2.3.7p456
Gem Version:	2.6.14
Bundler Version:1.13.7
Rake Version:	12.3.1
Redis Version:	3.2.11
Git Version:	2.16.3
Sidekiq Version:5.0.5
Go Version:	unknown
GitLab information
Version:	10.8.0
Revision:	55e4a0b
Directory:	/opt/gitlab/embedded/service/gitlab-rails
DB Adapter:	postgresql
URL:		https://xxx.xxxxxxxxx.xxx
HTTP Clone URL:	https://xxx.xxxxxxxxx.xxx/some-group/some-project.git
SSH Clone URL:	git@xxx.xxxxxxxxx.xxx:some-group/some-project.git
Using LDAP:	no
Using Omniauth:	no
GitLab Shell
Version:	7.1.2
Repository storage paths:

• default: /var/opt/gitlab/git-data/repositories Hooks: /opt/gitlab/embedded/service/gitlab-shell/hooks Git: /opt/gitlab/embedded/bin/git

Results of GitLab application Check

Expand for output related to the GitLab application check

(For installations with omnibus-gitlab package run and paste the output of:
sudo gitlab-rake gitlab:check SANITIZE=true)
docker exec -it gitlab gitlab-rake gitlab:check SANITIZE=true
Checking GitLab Shell ...
GitLab Shell version >= 7.1.2 ? ... OK (7.1.2)
Repo base directory exists?
default... yes
Repo storage directories are symlinks?
default... no
Repo paths owned by git:root, or git:git?
default... yes
Repo paths access is drwxrws---?
default... yes
hooks directories in repos are links: ...
8/4 ... ok
9/5 ... repository is empty
9/6 ... repository is empty
8/7 ... ok
11/8 ... ok
11/10 ... ok
11/11 ... ok
11/12 ... ok
2/13 ... ok
5/14 ... ok
5/15 ... ok
10/16 ... ok
2/19 ... ok
11/25 ... repository is empty
Running /opt/gitlab/embedded/service/gitlab-shell/bin/check
Check GitLab API access: OK
Redis available via internal API: OK
Access to /var/opt/gitlab/.ssh/authorized_keys: OK
gitlab-shell self-check successful
Checking GitLab Shell ... Finished
Checking Sidekiq ...
Running? ... yes
Number of Sidekiq processes ... 1
Checking Sidekiq ... Finished
Reply by email is disabled in config/gitlab.yml
Checking LDAP ...
LDAP is disabled in config/gitlab.yml
Checking LDAP ... Finished
Checking GitLab ...
Git configured correctly? ... yes
Database config exists? ... yes
All migrations up? ... yes
Database contains orphaned GroupMembers? ... no
GitLab config exists? ... yes
GitLab config up to date? ... yes
Log directory writable? ... yes
Tmp directory writable? ... yes
Uploads directory exists? ... yes
Uploads directory has correct permissions? ... yes
Uploads directory tmp has correct permissions? ... yes
Init script exists? ... skipped (omnibus-gitlab has no init script)
Init script up-to-date? ... skipped (omnibus-gitlab has no init script)
Projects have namespace: ...
8/4 ... yes
9/5 ... yes
9/6 ... yes
8/7 ... yes
11/8 ... yes
11/10 ... yes
11/11 ... yes
11/12 ... yes
2/13 ... yes
5/14 ... yes
5/15 ... yes
10/16 ... yes
2/19 ... yes
11/25 ... yes
Redis version >= 2.8.0? ... yes
Ruby version >= 2.3.5 ? ... yes (2.3.7)
Git version >= 2.9.5 ? ... yes (2.16.3)
Git user has default SSH configuration? ... yes
Active users: ... 1
Checking GitLab ... Finished

Possible fixes

(If you can, link to the line of code that might be responsible for the problem)

/label ~bug