Milestone burndown chart broken after moving issues between milestones

Summary

I moved all issues from 2 closed milestones to two new milestones. Now the burndown chart in the new milestones is broken and does not reflect the data.

Steps to reproduce

  1. Open two milestones, A & B.
  2. Add issues over time.
  3. See a working burndown chart as issues are closed over time.
  4. Close the milestones after its date has expired.
  5. Create two new milestones, C & D.
  6. Move issues from both A & B into C and from both A & B into D.
  7. Look at the burndown charts in C & D.

Example Project

That would take me several days to do, since I cannot move the clock.

What is the current bug behavior?

"-1 issues" on random dates. Chart line does not reflect the data.

What is the expected correct behavior?

Chart line reflects the data.

Relevant logs and/or screenshots

image__2_

Output of checks

(If you are reporting a bug on GitLab.com, write: This bug happens 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)


(For installations from source run and paste the output of:
sudo -u git -H bundle exec rake gitlab:env:info RAILS_ENV=production)

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)


(For installations from source run and paste the output of:
sudo -u git -H bundle exec rake gitlab:check RAILS_ENV=production SANITIZE=true)


(we will only investigate if the tests are passing)

Possible fixes

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

Edited by Marlon Richert