[BE] VA Profile issue: Investigate increase in ADDRVAL205 errors

[Samara-Strauss]

Background

@tpharrison while you were out on vacation, someone from VA Profile got in touch with us to let us know that there was an increase in ADDRVAL205 errors. It sounds like this has something to do with us sending over the value Nullinstead of an empty field for zip codes. I've forwarded you the whole thread, but here are key parts of it:

On January 23rd we saw an increase/spike of completed failures (Around 2400) for the PUT requests to vaprofile’s “/contact-information-hub/cuf/contact-information/v1/addresses” endpoint. These came from VETSGOV as the source. They appeared mostly on January 23rd.

The error we returned was ADDRVAL205 addressBio.InvalidRequestPostalCode Only one of either zipCode5 or international postal code is required

I thought it was strange, because the zipcode4 and zip were populated but the intPostalCode was showing "null". I asked the TL and they stated, that VETSGOV is actually sending “null” (the 4 character string), not an empty field. That appears to be an oversight on the VETSGOV code, or perhaps maybe someone ran a batch? And sent an actual string versus an empty value.

The way VAProfile’s code works, the string text ‘null’ is not the same as an empty string and will generate this error.

---

There is a USA postal code (and zip+4 usually). But the international postal code data has the word NULL in it instead of just being empty. “NULL” isn’t a valid postal code (I hope not at least!) so we throw that error. (The string “null’ is a 4 character text string, where “” is actually an empty string or a null string. Doesn’t sound like much of a difference to us but code thinks different. 😊 )

Tasks

• [ ] Review this ticket/email thread
• [ ] Investigate what's going on
• [ ] If this is as simple as us sending Nullinstead of an empty field, fix the bug in the code
• [ ] If this is less simple/a different problem, let's regroup on next steps

[tpharrison]

@Samara-Strauss Sentry wasn't showing any of these errors from our controllers, so I thought it might be related to the mobile team's controller. I reached out to Andrew Herzberg and he confirmed...

Hey Tom, yup, that assessment looks accurate. We discovered that our endpoint was getting called with some malformed parameters using the string “null” and such. Our FE has solved the issue but I don’t think it’s been pushed to the production app yet. It was while looking into that issue that I discovered the issue with the international address that I brought to you which I think may still be a separate issue since that address coming from the profile doesn’t match the Base address model in vets-api before mobile touches it.

The above fix should be going to production end of February.

The international address issue that Andrew referred to above has been captured in #52786. Do you want me to close this ticket and pull #52786 into this sprint?

[Samara-Strauss]

Thank you, Tom! Just following up formally even though we talked about this in planning. I'll loop back to VA Profile on this, and feel free to pull #52786 back into this sprint.