IIR - Update VAPRO Contact Lookup to Filter by Valid Phone Numbers

[mjones-oddball]

User Story - Business Need

Currently, VA Notify attempts to deliver SMS to any mobile phone number found in VA Profile. Sometimes these SMS fail because the "mobile" phone recorded in VA Profile is actually a landline or other invalid type for texting. Rather than attempting to text a number that will not succeed, we should use the phone validation data provided by VAPRO to determine if it makes sense to proceed to delivery, or fail and alert the client (via callbacks) that the phone number was invalid - thus making the person unreachable by SMS.

See IIR-900

• [ ] Ticket is understood, and QA has been contacted (if the ticket has a QA label).

User Story(ies)

As a Business
I want to know if the Veteran is unreachable by SMS due to an invalid phone number So that I can ensure they are receiving the information I'm sending them, and determine if alternate communications are required

As VA Notify
I want to determine if a phone number is valid before proceeding to delivery So that I can efficiently process notifications, and deliver status information back to businesses ASAP if a recipient is unreachable

Additional Info and Resources

• Parent spike 792 with details in the comments
• Profile API Notes
• Metadata about phone numbers may be available from the Profile API, which would allow us to confirm that a number is a cell phone. This lives in the response to a Contact Information request under telephones, then in the TelephoneResponse object we're interested in classification then classificationCode.
• Classifications:

  {
  "classificationList": [
  {
    "classificationCode": 0,
    "classificationName": "MOBILE"
  },
  {
    "classificationCode": 1,
    "classificationName": "LANDLINE"
  },
  {
    "classificationCode": 2,
    "classificationName": "VOIP"
  },
  {
    "classificationCode": 3,
    "classificationName": "INVALID"
  },
  {
    "classificationCode": 4,
    "classificationName": "OTHER"
  },
  {
    "classificationCode": 5,
    "classificationName": "PREPAID"
  }
  ]
  }

Acceptance Criteria

• [ ] Valid phone number proceeds with delivery

GIVEN VA Profile returns a mobile phone number WHEN the classification is mobile (0), voip (2), prepaid (5) OR a classification is not provided THEN proceed to SMS delivery

• [ ] Invalid phone number fails prior to delivery and status is sent to client via callback if applicable

GIVEN VA Profile returns a mobile phone number WHEN the classification is landline (1), invalid (3), or other (4) THEN raise a VAProfileNonRetryableException with status: permanent-failure and status_reason: Phone number is invalid

QA Considerations

Potential Dependencies

[mjones-oddball]

Noting that we determined other was not a valid type because of AWS's reply: Occasionally, the response from the phone number validation service includes a PhoneType value of OTHER. The service might return this kind of response in the following situations:

• The phone number is a toll-free (freephone) number.
• The phone number is reserved for use in TV shows and movies, such as North American phone numbers that begin with 555.
• The phone number includes an area code that is not currently in use, such as the 999 area code in North America.
• The phone number is reserved for some other purpose.

VA Profile said there were currently 32,379 flagged as OTHER as of 9/3.

Other breakdowns below:

[cris-oddball]

@EvanParish and @AdamKing0126 to sync on this before the branch is deployed, then Evan will sync with me for testing notes.

[cris-oddball]

Evan touched base with me about testing. We discussed:

• setting the feature flag to False in Perf, Staging, Prod, that way I can turn it on in Perf when able to test and can ensure that with the test flag as false, everything works as expected
• adding a task definition file for prod now
• adding celery task definitions.

[cris-oddball]

PR is approved and merged. Sending this to Perf and holding it there until Monday.

[cris-oddball]

On Perf, with Flag disabled, I have verified that Pinpoint is still handling Phone Validation failures by changing a test user's contact Mobile to a prefix 555 number and observing in the logs a Pinpoint event_type=_SMS.FAILURE and observing the test logs for the feature:

V3 Profile -- VA_PROFILE_V3_IDENTIFY_MOBILE_TELEPHONE_NUMBERS is not enabled. Will not check classification info.

Will deploy this up to Prod (staging and prod feature flags are off), then cut a branch to flip Perf on and test that the feature flag works as expected.