Reinstate appeals that were incorrectly opted into RAMP

[shanear]

There are a couple of appeals that we need to roll back out of RAMP. I will probably need Chris's help on this, and we will probably want to create a script for it

Acceptance Criteria

• There should be a mechanism to rollback RampElections and reinstate appeals associated with them. We should record the reason for doing this.

[shanear]

Apparently there may be some issues with doing this. Blocked until we figure out what's going on.

[cmgiven]

Any more details here?

[shanear]

Turns out these might all not need to be reinstated. Two have forms uploaded and two seem like they should be there and aren't. Holding indefinitely. @abbyraskinUSDS is following up today with Claire

[abbyraskinUSDS]

I gave Claire the (proverbial) download. She is looking into these.

[shanear]

@cmgiven we have a ton of requests from Claire to reinstate appeals that were incorrectly opted in to RAMP. Is there a process to verify this? Or should I take them at their word?

Right now we have reason to believe they are cancelling the RAMP EP, but not reinstating the appeal, causing these appeals to get "lost" 😢

see: https://github.com/department-of-veterans-affairs/appeals-design-research/issues/739

[cmgiven]

So is the ask to verify that the Caseflow-created EP has been cancelled?

[shanear]

Confirmed that there are numerous RAMP elections that were incorrectly processed. Right now they are cancelling the RAMP EP and not reinstating the VACOLS appeal, which is obviously bad. We will need a script.

[shanear]

This passed for the original appeal. But failed with a strange error for the remand:

[2018-04-16 22:07:26 -0400]    (0.6ms)  ROLLBACK
ActiveRecord::StatementInvalid: OCIError: ORA-06502: PL/SQL: numeric or value error: character string buffer too small
ORA-06512: at "VACOLS.BRIEFF_DELETE", line 6
ORA-04088: error during execution of trigger 'VACOLS.BRIEFF_DELETE': DELETE FROM "VACOLS"."BRIEFF" WHERE "VACOLS"."BRIEFF"."BFKEY" = :a1
    from app/services/appeal_repository.rb:484:in `block in reopen_remand!'
    from app/services/appeal_repository.rb:472:in `reopen_remand!'
    from app/models/appeal.rb:819:in `reopen_single'
    from app/models/appeal.rb:720:in `block (2 levels) in reopen'
    from app/models/appeal.rb:719:in `each'
    from app/models/appeal.rb:719:in `block in reopen'
    from app/services/appeal_repository.rb:10:in `block in transaction'
    from app/services/appeal_repository.rb:9:in `transaction'
    from app/models/appeal.rb:718:in `reopen'
    from app/models/ramp_election_rollback.rb:24:in `reopen_vacols_appeals!'
    from (irb):49

any ideas on what might be causing this @cmgiven ?

[cmgiven]

We saw this happen with an audit table here: https://dsva.slack.com/archives/C54QCEHAL/p1523466226000523

Looks like something’s kicking in when we try to delete a row. We should reach out to Jed tomorrow.

[shanear]

validation is blocked on:

https://github.com/department-of-veterans-affairs/appeals-deployment/issues/1381

[shanear]

Alright reopened both a remand and a orginal in UAT.

@cmgiven to verify that the appeals were correctly reopened: vacols_id remand 1234783 vacols_id original 1006081