Closed utsab closed 1 year ago
Hi Utsab, thank you for posting the issue. Our team (Chris @chrisdedman, Luke @LukeBerryCS, and I) is working on it now. Could you please assign it to us? Thank you
@DaleMcGrew In the process of making a unit test for voterPlanListRetrieve
endpoint, @chrisdedman, @LukeBerryCS, and I discovered an inconsistency in the way that the information is retrieved from the database compared to other endpoints.
voter_plan_save_view()
voter_we_vote_id = fetch_voter_we_vote_id_from_voter_device_link(voter_device_id)
results = voter_manager.retrieve_voter_by_id(voter_id, read_only=True)
And as you see, one of the arguments is read_only = True
, which means it reads from the read_only
database instead of default
database.
The trail of function calls:
voter_email_address_retrieve_view()
voter_email_address_retrieve_for_api()
voter_results = voter_manager.retrieve_voter_from_voter_device_id(voter_device_id, read_only=False)
Note that now read_only=False
, so the voterEmailAddressRetrieve
endpoint reads from the default
database whereas voterPlanListRetrieve
reads from the read_only
database. Thus, there is an inconsistency here. One consequence of this inconsistency is: the unit test for voterPlanListRetrieve
endpoint seems to fail because (I'm guessing) that the read_only
database does not get updated as quickly as the default
database.
Change voterPlanListRetrieve
to also read from default
instead of read_only
:
results = voter_manager.retrieve_voter_by_id(voter_id, read_only=False)
What do you think of this solution?
@tranngocsongtruc, @chrisdedman, @LukeBerryCS - I spoke with Dale regarding your issue. He suggested one possible workaround. Before you read from the database to fetch the voter plan, add a sleep command to your test to make the test pause for 1-2 seconds. That should be enough time for the read-only database to get synchronized.
To write a unit test test, here are a few recommendations to get started: