Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Investigate odd mail task trees #13269

Closed
2 tasks
hschallhorn opened this issue Jan 27, 2020 · 7 comments
Closed
2 tasks

Investigate odd mail task trees #13269

hschallhorn opened this issue Jan 27, 2020 · 7 comments
Labels
Priority: Medium Blocking issue w/workaround, or "second in" priority for new work. Product: caseflow-queue Team: Echo 🐬 Type: Investigation

Comments

@hschallhorn
Copy link
Contributor

Found some odd task trees while investigating VLJ support issues

tasks_assigned_to_colocated = Task.open.where(assigned_to: Colocated.singleton)
tasks_under_tasks_assigned_to_colocated = Task.open.where(parent: tasks_assigned_to_colocated)
tasks_under_tasks_assigned_to_colocated.group(:assigned_to_type).count
=> {"User"=>3971, "Organization"=>4}
# Weird, let's look at these org tasks
organization_tasks_under_tasks_assigned_to_colocated = tasks_under_tasks_assigned_to_colocated.where(assigned_to_type: Organization.name)
puts organization_tasks_under_tasks_assigned_to_colocated.map { |task| task.appeal.structure_render(:assigned_to_type, :assigned_to_id) }
Appeal 29346 [assigned_to_type, assigned_to_id]
└── RootTask Organization, 2
    ├── DistributionTask Organization, 2
    ├── EvidenceOrArgumentMailTask Organization, 18
       └── EvidenceOrArgumentMailTask Organization, 23
           ├── EvidenceOrArgumentMailTask User, 2480
           └── EvidenceOrArgumentMailTask Organization, 23
               └── EvidenceOrArgumentMailTask User, 1379
                   └── EvidenceOrArgumentMailTask Organization, 18
    ├── EvidenceOrArgumentMailTask Organization, 18
       └── EvidenceOrArgumentMailTask Organization, 23
           └── EvidenceOrArgumentMailTask User, 2227
    └── EvidenceOrArgumentMailTask Organization, 18
        └── EvidenceOrArgumentMailTask Organization, 23
            └── EvidenceOrArgumentMailTask User, 2012
Appeal 19124 [assigned_to_type, assigned_to_id]
└── RootTask Organization, 2
    ├── TrackVeteranTask Organization, 295
    ├── DistributionTask Organization, 2
       └── EvidenceSubmissionWindowTask Organization, 18
    ├── EvidenceOrArgumentMailTask Organization, 18
       └── EvidenceOrArgumentMailTask Organization, 23
           ├── EvidenceOrArgumentMailTask User, 2480
           └── EvidenceOrArgumentMailTask Organization, 23
               └── EvidenceOrArgumentMailTask User, 1782
                   └── Task Organization, 330
    ├── JudgeAssignTask User, 1241
    ├── JudgeDecisionReviewTask User, 1473
       └── AttorneyTask User, 2051
    └── BvaDispatchTask Organization, 19
        ├── BvaDispatchTask User, 2111
        └── BvaDispatchTask User, 2010
Appeal 15511 [assigned_to_type, assigned_to_id]
└── RootTask Organization, 2
    ├── DistributionTask Organization, 2
       ├── EvidenceSubmissionWindowTask Organization, 18
       ├── PowerOfAttorneyRelatedMailTask Organization, 18
          └── PowerOfAttorneyRelatedMailTask Organization, 23
              └── PowerOfAttorneyRelatedMailTask User, 2141
       └── PowerOfAttorneyRelatedMailTask Organization, 18
           └── PowerOfAttorneyRelatedMailTask Organization, 23
               ├── PowerOfAttorneyRelatedMailTask User, 10425
               └── PowerOfAttorneyRelatedMailTask Organization, 23
                   └── PowerOfAttorneyRelatedMailTask User, 1782
                       └── Task Organization, 330
    ├── TrackVeteranTask Organization, 445
    └── TrackVeteranTask Organization, 446
Appeal 16167 [assigned_to_type, assigned_to_id]
└── RootTask Organization, 2
    ├── TrackVeteranTask Organization, 309
    ├── DistributionTask Organization, 2
    ├── PowerOfAttorneyRelatedMailTask Organization, 18
       └── PowerOfAttorneyRelatedMailTask Organization, 23
           └── PowerOfAttorneyRelatedMailTask User, 2227
    └── ExtensionRequestMailTask Organization, 18
        └── ExtensionRequestMailTask Organization, 23
            ├── ExtensionRequestMailTask User, 10425
            └── ExtensionRequestMailTask Organization, 23
                └── ExtensionRequestMailTask User, 1829
                    └── Task Organization, 202

AC

  • Investigate how or why task trees got to this state
  • File ticket to fix if needed
@hschallhorn hschallhorn added Team: Echo 🐬 Product: caseflow-queue Type: Investigation Priority: Medium Blocking issue w/workaround, or "second in" priority for new work. labels Jan 27, 2020
@yoomlam
Copy link
Contributor

yoomlam commented Jan 31, 2020

@ajspotts
Copy link
Contributor

What is this graph?

1 | 
2 | |||||||||||
3 | 
5 | 
8 |  

Time-boxing to a 2. Don't spend more than a 2's level of effort investigating this ticket.

@yoomlam
Copy link
Contributor

yoomlam commented Feb 21, 2020

Only 1 child org task was found: => {"User"=>3743, "Organization"=>1}

child_org_task.id
=> 465588

Here's its appeal tree:

Appeal 16167 (direct_review)                    ID     STATUS      ASGN_BY     ASGN_TO     CREATED_AT              UPDATED_AT
└── RootTask                                    315035 on_hold                 Bva         2019-08-07 17:35:21 UTC 2019-08-07 17:35:21 UTC
    ├── TrackVeteranTask                        315036 in_progress             PrivateBar  2019-08-07 17:35:21 UTC 2019-08-07 17:35:21 UTC
    ├── DistributionTask                        315037 assigned                Bva         2019-08-07 17:35:21 UTC 2019-08-07 17:35:21 UTC
    ├── PowerOfAttorneyRelatedMailTask          321410 completed               MailTeam    2019-08-09 18:25:36 UTC 2019-08-12 18:04:16 UTC
    │   └── PowerOfAttorneyRelatedMailTask      321411 completed   BVAMJWRIGHT Colocated   2019-08-09 18:25:36 UTC 2019-08-12 18:04:16 UTC
    │       └── PowerOfAttorneyRelatedMailTask  321412 completed   BVAMJWRIGHT VACODRAYTM  2019-08-09 18:25:41 UTC 2019-08-12 18:04:16 UTC
    └── ExtensionRequestMailTask                341040 on_hold                 MailTeam    2019-08-20 18:57:54 UTC 2019-08-20 18:58:00 UTC
        └── ExtensionRequestMailTask            341041 on_hold     BVAMJWRIGHT Colocated   2019-08-20 18:57:54 UTC 2019-08-20 18:58:00 UTC
            ├── ExtensionRequestMailTask        341042 cancelled   BVAMJWRIGHT VSCLHALL    2019-08-20 18:58:00 UTC 2019-10-11 14:33:20 UTC
            └── ExtensionRequestMailTask        465588 on_hold     BVAMJWRIGHT Colocated   2019-10-11 14:33:12 UTC 2019-10-11 14:33:20 UTC
                └── ExtensionRequestMailTask    465589 on_hold     BVAMJWRIGHT BVALLEWIS   2019-10-11 14:33:20 UTC 2019-10-15 11:59:05 UTC
                    └── Task                    467229 assigned    BVALLEWIS   PrivacyTeam 2019-10-15 11:59:05 UTC 2019-11-21 20:18:30 UTC

My interpretation of events that resulted in the tree:

  • On 2019-08-20, 3 tasks were created consecutively, 341040 through 341042.
    • 341042 was auto-assigned(?) to HALL within 10 seconds
  • On 2019-10-11 14:33:12, 465588 was created and assigned to Colocated team.
    • 8 seconds later, a child task 465589 is created and assigned to LEWIS (at 2019-10-11 14:33:20.052448000; curious that assigned_at is 2019-08-20). 341042 assigned to HALL is cancelled (at 2019-10-11 14:33:20.073758593).
  • On 2019-10-15, LEWIS assigns it to PrivacyTeam

@yoomlam
Copy link
Contributor

yoomlam commented Feb 21, 2020

@hschallhorn What is considered odd about these mail task trees?

Without looking at the code to see how the task tree should be structured, I personally would expect either:

  1. 465588 to not exist and 465589 should be at the same level as 341042, or
  2. 465588 should be at the same level as 341041 and 341041 would be cancelled.

To me, 465588 is the same task as 341041.

More importantly, while the task tree may be odd, how does it adversely affect Caseflow behavior?

@hschallhorn
Copy link
Contributor Author

What is considered odd about these mail task trees?

We don't expect colocated org tasks to be children of a colocated user's task

how does it adversely affect Caseflow behavior?

My concern is with reporting and these tasks possibly not closing correctly when complete.

@yoomlam
Copy link
Contributor

yoomlam commented Feb 26, 2020

We don't expect colocated org tasks to be children of a colocated user's task

I assume you are referring to PrivacyTeam's org Task 467229 being a child of user BVALLEWIS's ExtensionRequestMailTask 465589. (I'm assuming the PrivacyTeam's org task is considered a Colocated org task.)

Some more info:

  • 341042 was cancelled by css_id: CASEFLOW1 at the exact same time 465589 was created.
    • Perhaps this was done by a BatTeam member?
  • 465589's status changed from assigned to in_progress at 2019-10-15 11:55:02.008648841
  • 4 minutes later, it was put on_hold because of child task 467229 being created.
    • That child task has instructions: 'FOIA action pending ', which is different that all other ExtensionRequestMailTasks which have instruction "Extension Request for 90 days"
      • Given the instructions: 'FOIA action pending ', why is there no FOIA-related tasks?
    • Almost a month later, the task type was changed from GenericTask to Task on 2019-11-21 20:18:30.861395619 by whodunnit: nil.
  • I couldn't find any relevant creation of ExtensionRequestMailTask in the code by grepping.
  • Could any of this be a result of ChangeTypeController, which calls MailTask.create_twin_of_type?
  • I recreated the appeal in dev, then in the UI, BVALSPORER re-assigned task 1149 to CSS_ID1, who re-assigned their task to the PrivacyTeam. The resulting task tree is more reasonable:
└── RootTask                                  1142 on_hold                     Bva         2020-02-26 02:08:07 UTC
    ├── DistributionTask                      1143 assigned                    Bva         2020-02-26 02:08:56 UTC
    └── ExtensionRequestMailTask              1147 on_hold                     MailTeam    2020-02-26 02:39:45 UTC
        └── ExtensionRequestMailTask          1148 on_hold   VLJ_SUPPORT_ADMIN Colocated   2020-02-26 02:45:20 UTC
            ├── ExtensionRequestMailTask      1149 cancelled VLJ_SUPPORT_ADMIN BVALSPORER  2020-02-26 03:39:34 UTC
            └── ExtensionRequestMailTask      1150 on_hold   BVALSPORER        CSS_ID1     2020-02-26 03:42:52 UTC
                └── ExtensionRequestMailTask  1151 assigned  CSS_ID1           PrivacyTeam 2020-02-26 03:42:52 UTC

I've well surpassed the timebox. Regarding the ACs, since there's only this 1 "odd" appeal, I suggest changing this ticket to fix this appeal to perhaps look like the one I created in dev.
@hschallhorn Thoughts?

@hschallhorn
Copy link
Contributor Author

hschallhorn commented Feb 26, 2020

I was actually referring to the ExtensionRequestMailTask assigned to colocated with a ExtensionRequestMailTask assigned to colocated parent (465588 and 341041). Essentially an org task where we would expect a user task to be (definitely misspoke, apologies)

why is there no FOIA-related tasks?

Privacy act tasks and foia tasks are kinda interchangeable. FoiaTasks did not exist until we started automatically routing foia colocated tasks to the privacy team.

Almost a month later, the task type was changed from GenericTask to Task on 2019-11-21 20:18:30.861395619 by whodunnit: nil.

This was probably done by @kevmo when migrating GenericTask to Task

I've well surpassed the timebox

I'm still not sure we've figured out how this happened and we still don't want these to occur in the future. I'll toss it into backlog and possibly look into it as a batteam activity.

@yoomlam yoomlam removed their assignment Mar 17, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Priority: Medium Blocking issue w/workaround, or "second in" priority for new work. Product: caseflow-queue Team: Echo 🐬 Type: Investigation
Projects
None yet
Development

No branches or pull requests

4 participants