It shouldn't.
Description
Description
Event Timeline
Comment Actions
Duplicate isn't a separate status in Phabricator; it's just "resolved" as far as the status is concerned.
Comment Actions
Correction: Duplicate is a separate status in Phabricator, and Phlogiston does preserve this.
phlogiston=# select new_value, count(*) from maniphest_transaction where transaction_type = 'status' group by new_value;
new_value | count
-----------+--------
| 3
declined | 10449
duplicate | 245
invalid | 7861
needsinfo | 16
open | 182627
resolved | 76668
stalled | 4145In the current design, all duplicate, invalid, or declined tasks are deleted during at the beginning of each reporting cycle.
DELETE FROM task_on_date_recategorized
WHERE (status = 'duplicate'
OR status = 'invalid'
OR status = 'declined')
AND scope = $1;This particular task, 120476, is not getting deleted because ... the transaction log shows it was set to "resolved", not "duplicate".
phlogiston=# select date_modified, old_value, new_value from maniphest_transaction where task_id = 120476 and transaction_type='status' order by date_modified;
date_modified | old_value | new_value
------------------------+-----------+-----------
2015-12-05 00:16:49+00 | null | open
2015-12-07 21:55:33+00 | open | resolved
(2 rows)Could this be a quirk of the data import from Bugzilla? No, this all happened in Phabricator, right? Also, according to the task history, the task was marked resolved/duplicate twice. The second time, by you in Feb 2016, isn't in the transaction log. New hypothesis: some kind of data corruption within Phabricator's database?
Comment Actions
Huh.
No, this all happened in Phabricator, right?
Right.
Also, according to the task history, the task was marked resolved/duplicate twice. The second time, by you in Feb 2016, isn't in the transaction log. New hypothesis: some kind of data corruption within Phabricator's database?
Looks like Phab was a bit broken with the first one; Danny duped it, but it was marked as R not D. 🤷🏽♂️