Page MenuHomePhabricator
Create Task
Maniphest T11333

Inconsistency in task tags
Closed, InvalidPublic
Actions

Assigned To
None
Authored By
jasonfsmitty
Jul 15 2016, 12:47 PM
Tags
Referenced Files
F1725033: trans1.json
Jul 15 2016, 3:18 PM
F1725032: trans2.json
Jul 15 2016, 3:18 PM
Subscribers
chad
epriestley
jasonfsmitty

Description

We have a project Firmware with workboard columns Backlog and Unscheduled. It also has various subprojects, including 11.9.0.

While running week 14 stable, we used the Firmware workboard to drag and drop a number of tasks from the 11.9.0 subproject into the Firmware > Unscheduled column. Things appeared to work correctly.

A couple days ago we upgraded to week 28 stable, and now in the Firmware workboard, tasks are appearing in both the Unscheduled and 11.9.0 columns. The tasks do not appear on the 11.9.0 workboard, and are not found in a maniphest query for 11.9.0. Looking at the task itself, it's tagged as Firmware (unscheduled) (11.9.0) as if it was in both columns, but editing the task details shows it as tagged only in the Firmware project, not the 11.9.0 subproject.

Looking at the task, I see the expected <user> edited projects, added Firmware; removed Firmware (11.9.0) for when it was originally moved. In the Firmware workboard, dragging the task from 11.9.0 to Unscheduled seems to clean it all up, and the task once again appears to be in a consistent state. It does not create a new <user> edited projects... transaction.

So while I'm able to clean things up and move forward, I only noticed this instance because of the fair number of tasks involved. I'm worried other smaller groups of tasks may be in this state and are going unnoticed. I would appreciate guidance on how to clean this up across our entire install.

This may be a dup of T10638, but thought it was worth a new task to describe our slightly different symptoms.

Related Objects

Event Timeline

jasonfsmitty created this task.Jul 15 2016, 12:47 PM
chad added a subscriber: chad.Jul 15 2016, 1:55 PM

What are the minimum set of steps on a new, clean install we can follow to reproduce the error your seeing locally?

chad added a comment.Jul 15 2016, 2:02 PM

For example, 11.9.0 sounds like a Milestone, not a subproject. Is that correct?

jasonfsmitty added a comment.EditedJul 15 2016, 2:58 PM
In T11333#186009, @chad wrote:

For example, 11.9.0 sounds like a Milestone, not a subproject. Is that correct?

Sorry, yes it's a milestone. We're not using any non-milestone subprojects so I tend to use the names interchangeably.

In T11333#186007, @chad wrote:

What are the minimum set of steps on a new, clean install we can follow to reproduce the error your seeing locally?

There may be some extra steps here, but I think this covers what we did. Unfortunately this spans several months, and I'm not in a position to setup another install and walk through this to test.

  1. Setup an install based around 2016 week 8 stable (ad53db0979de40e85ff759da8102a42a14e30f10).
  2. Create a project F and add a milestone M.
  3. Create a task, and tag it with M.
  4. From the F workboard, drag the task from M to a normal column in F (not sure if it matters, but in our case the destination was a custom column added to F, but the default column probably works too).

Not sure if this is necessary, but it's what we did so thought I'd mention ...

Perform normal upgrade to 2016 week 14 stable (fea2389066edf3ad0a7547ae12d8e988428a4f5c)

And finally:

  1. Perform normal upgrade to 2016 week 28 stable (9da15fd7ab7071e3b7361463229abd4e918d9d94)
  2. View F workboard. Task appears in in both the F column, and the M milestone, but is not actually in M as described above.

I can't say with 100% certainty that the task was displayed correctly while running week 14. I just know that we did run that version up until a few days ago when we bumped to week 28.

chad added a comment.Jul 15 2016, 3:16 PM

There may be some extra steps here, but I think this covers what we did. Unfortunately this spans several months, and I'm not in a position to setup another install and walk through this to test.

We require bug reports be reproducible by the reporter under our basic "free support" model. The basic idea is it's better if you spend 1-2 hours than us spending 1-2 days guessing the problem though back and forth questioning.

One thing you could do is test a current version of Phabricator with your steps on http://phacility.com with a free test instance.

jasonfsmitty added a comment.Jul 15 2016, 3:18 PM

FWIW, there are the transaction logs (via conduit) for a task that was experiencing the issue.

trans2.json19 KBDownload
- This is while it was in the weird state. Transaction ID 67571 is when the task was originally moved from 11.9.0 to the Firmware project:

  • PHID-PROJ-qsk7qp7kov4athl6udpb - the 11.9.0 milestone being moved from
  • PHID-PROJ-65n6suxyxfhxshfh42zj - the Firmware project being moved to.

trans1.json18 KBDownload
- after 'fixing' it by drag-and-dropping it in the Firmware workboard from 11.9.0 to a normal column, new transaction is 82790.

I diff the maniphest.info json as well, but the only change was the modified date.

jasonfsmitty added a comment.Jul 15 2016, 3:18 PM
In T11333#186012, @chad wrote:

We require bug reports be reproducible by the reporter under our basic "free support" model. The basic idea is it's better if you spend 1-2 hours than us spending 1-2 days guessing the problem though back and forth questioning.

One thing you could do is test a current version of Phabricator with your steps on http://phacility.com with a free test instance.

Understood. I'll try in phacility.

jasonfsmitty added a comment.Jul 15 2016, 4:19 PM

I have not been able to reproduce in phacility, and moving tasks around in our current install works correctly.

epriestley closed this task as Invalid.Jul 15 2016, 7:20 PM
epriestley added a subscriber: epriestley.

Since there doesn't appear to be a way to reproduce this at HEAD, we can't move forward.

Phabricator · Built by Phacility