SPIKE - Investigate slow query to update contact records when creating a transaction.

[mjtravers]

During the Sprint-34 FEC demo, it was noticed the changes to a contact while creating a new transaction were not appearing on the form inputs. It was noticed in the api cloud.gov logs that updates to the contact records was taking up to 5 seconds to run.

To duplicate the issue:

Add a particular contact to 10 transactions. Update the name of the contact on the contact screen in the contact section of the site. Immediately click to a transaction that uses that contact and see if the name has been updated. While doing this, monitor the api logs on cloud.gov to see the length of time the contact update takes to execute.

BA note: There was a contact who had 11 transactions plus a couple loans that had carried forward on multiple reports. I updated the contact first name in Contact Management and none of the transactions were updated.

Tasks for this ticket:

NO CODING FOR THIS TICKET. JUST A WRITE UP IN THE COMMENTS AS TO WHY THE CONTACT SAVE IS TAKING 5 SECONDS OR MORE.

Possible code fixes below depending on what is discovered

1. Performance test the saving of updated contact records for contacts on a large number of transactions. If that is the issue, add indexes to database tables to improve performance or, if that does not increase the query speed, refactor the code. If not the issue, report to the team the cause of the slow down.

2. Investigate and fix why the app returned from the contact save before it had completed. Add a spinner to hold the app until the back-end returns with a status code.

QA Notes

null

DEV Notes

null

Design

null

See full ticket and images here: FECFILE-253

[WiseQA]

@mjtravers looked over ticket as we talked. Looks good, when we point as this backend ticket I will retest the contacts performance on the front end.

[mjtravers]

SPIKE RESULTS: The slow contact queries were an issue that came out of the original requirement that when contact data on a transaction is changed, the change only affected transaction on future reports. The database was tracking the versions of contact information to make this happen which was slowing down saves. The requirement was changed so that when a contact is changed anywhere (in contacts management, a transaction, or a F1M report) that the change is posted everywhere and is not date dependent. The change to increase performance is to refactor this old requirement out of the design of the database so contact versioning is no longer implemented.

This change was implemented in #1555

[WiseQA]

There is no QA review needed on this SPIKE ticket. Moved to Stage Ready