Page MenuHomePhabricator

Burnup Chart does not appear to be working
Closed, ResolvedPublic

Assigned To
Authored By
joshuaspence
May 1 2014, 11:53 PM
Referenced Files
F156294: burnup-before.png
May 18 2014, 5:53 AM
F156296: burnup-after.png
May 18 2014, 5:53 AM
F156270: Screen_Shot_2014-05-17_at_7.46.33_PM.png
May 18 2014, 3:05 AM
F156272: Screen_Shot_2014-05-17_at_8.03.45_PM.png
May 18 2014, 3:05 AM

Description

Burnup charts don't seem to be working on our install. More specifically, the chart does not seem to reflect the actual state of maniphest task. I have attached a screenshot which shows a steady decline in the plot. Interestingly, the date on which the decline began was the date that we performed a Phabricator upgrade (previously, we were 6 months behind HEAD).

{F149790}

Event Timeline

joshuaspence assigned this task to epriestley.
joshuaspence raised the priority of this task from to Needs Triage.
joshuaspence updated the task description. (Show Details)
joshuaspence added a project: Maniphest.
joshuaspence added a subscriber: joshuaspence.

Are you currently up to date? There was a bug with this for about a week, I think.

Oh ok.... do you know when it was fixed roughly?

That looks correct to me, yeah.

Ok, so after updating everything earlier today this problem still exists.

Based on D8682, it seems that the bug was related to not writing transactions. If this is the case, I guess that the graph would still be wrong for historical data, but I should expect it to be accurate in the future. Is this correct?

If this is the case, in order to actually fix the graph, I would have the recreate the relevant transaction history (which may not be possible)?

Yeah, there's no easy way to repair the historical data. Ideally this is just fixed by the Facts application, but that could be a while.

If you don't mind a couple hundred out-of-order transactions showing up on the affected tasks, I can probably give you a query/script to approximately repair things. Roughly, it should look like:

  • identify tasks with no creation transaction;
  • insert one for them.

...but the transaction will appear at insertion time even if backdated, because the queries order by primary autoincrement key.

You can use this script to repair the transaction tables, at least approximately. We don't actually show these transactions in the UI so there's no real downside to running it (except that it takes a minute to run):

<?php

require_once 'scripts/__init_script__.php';

$tasks = new LiskMigrationIterator(new ManiphestTask());
foreach ($tasks as $task) {
  $id = $task->getID();

  $xactions = id(new ManiphestTransactionQuery())
    ->setViewer(PhabricatorUser::getOmnipotentUser())
    ->withObjectPHIDs(array($task->getPHID()))
    ->execute();

  $found_create = false;
  foreach ($xactions as $xaction) {
    if ($xaction->getTransactionType() == ManiphestTransaction::TYPE_STATUS) {
      $old = $xaction->getOldValue();
      if ($old === null) {
        $found_create = true;
        break;
      }
    }
  }

  if ($found_create) {
    echo "T{$id}: Found create transaction.\n";
    continue;
  }

  echo "T{$id}: Creating synthetic transaction...\n";

  $content_source = PhabricatorContentSource::newConsoleSource();

  $xaction = id(new ManiphestTransaction())
    ->setTransactionType(ManiphestTransaction::TYPE_STATUS)
    ->setObjectPHID($task->getPHID())
    ->setViewPolicy(PhabricatorPolicies::POLICY_USER)
    ->setEditPolicy($task->getAuthorPHID())
    ->setAuthorPHID($task->getAuthorPHID())
    ->setDateCreated($task->getDateCreated())
    ->setDateModified($task->getDateCreated())
    ->setMetadataValue('synthetic:T4940', true)
    ->setContentSource($content_source)
    ->setOldValue(null)
    ->setNewValue('open');

  // NOTE: Uncomment this to actually do stuff.

//  $xaction->save();

}

I ran it on this install and it seemingly repaired the chart.

Before: depressing progress

Screen_Shot_2014-05-17_at_7.46.33_PM.png (407×1 px, 44 KB)

After: glorious eternal defeat

Screen_Shot_2014-05-17_at_8.03.45_PM.png (407×1 px, 43 KB)

(That weird spike is legitimate, some tester created a bunch of test tasks and then we closed them.)

I don't currently plan to automatically run this since it probably affected only a few installs very slightly and in a way that matters less over time, but let me know if you give this a shot and hit issues.

@epriestley, thanks that worked on our install.

Before:

burnup-before.png (402×1 px, 24 KB)

After:

burnup-after.png (401×1 px, 20 KB)

Time taken:

real	4m38.690s
user	2m4.776s
sys	0m54.035s