data-doge
commented
1 year ago @saderagsdale
I've had a chance to review the errors listed above and other errors that have been thrown recently. I have a sense of what changes would be necessary to resolve a substantial number of these name and address validation issues:
- We need to add a max length of 30 characters for
veteran_contact_information.veteran_address.cityon the front end, a max length of 35 characters forlast_term_school_information.address.address_line1, and a max length of 35 characters forschool_information.address.address_line1. This should be very simple to achieve using VA's form system. - We need to change how we represent UK addresses, specifically. Currently, if the veteran provides an
international_postal_code(i.e. GBR), we use anIsoCountryCodesclass to automatically expand that to "United Kingdom of Great Britain and Northern Ireland", which exceeds the 50 character limit for countries by two characters. We should consult with Linda and Baha. Ideally, we could simply truncate the country to 50 chars without creating any negative impact. - We need to change how we handle names and addresses with special characters (e.g. apostrophes, umlauts). BIS (and perhaps Corp DB) reject them. We could strip them out, replace them with a space, add front end validations preventing veterans from entering them, or advocate for the relevant datastore(s) to accept special characters.
- We need to fix some bugs around foreign military addresses. There are instances where a veteran inputs a city of APO, DPO, or FPO (indicating a foreign military address), but is still allowed to indicate a State address, state code, and zip code. BIS rejects this data because it expects a military_postal_code of either AE, AP, or AA for APO, DPO, and FPO addresses. Additionally, when a veteran indicates a foreign military address, our code deletes
cityfrom the payload we send to BIS. But BIS throws an error whencityisnull. We should consult with Linda and Baha to learn what data is expected for military addresses. - We should improve our logging around validation errors. Currently, I need to sift through enormous error messages returned by BIS to understand whether an error was a validation error, and if so, what kind of validation error. This makes it more difficult to assess the kinds of errors we are getting, and their relative proportions. The relevant part of BIS's error messages tend to start with a
ORA-*signature. So, it should be possible to extract the relevant portion of those error messages, and log them alongside the raw error message.
I'm going to quickly chat with Linda and Baha before providing a complexity estimate for the tasks above.
saderagsdale
Value Statement
As a software developer I want to investigate the effort to resolve validation errors related to dependency claims So that they don't cause claims to fail.
Background Context
We get a number of address and contact info validation errors from BGS's endpoints which prevent us from establishing a claim via BGS. Here are some examples:
ORA-02291: integrity constraint (CORPPROD.FK2_VNP_PTCPNT_ADDRS) violated - parent key not found: 1Invalid data for MLTY_POSTAL_TYThe goal of this ticket is to investigate the errors above and gauge the level of effort to resolve them.
Acceptance Criteria
Tasks
Out of Scope
Definition of Ready
Definition of Done