Skip to content

bug - missing expected distance records

DD-447

background

not all expected distance records existed.

problem(s)

Seemingly two-fold:

  1. Early Feb there were distance jobs re-run for all site/dr combinations. The jobs may not have all run - memory is hazy here, but there was some issue with background jobs running (queueing up hundreds of thousands) and some may have not run. The standard process when discrepancies are in place is to have someone reverify the address in question to recompute distances. However..
  2. Hospital site addresses were being stored with wrong timezone for address verification process to work with. Data was being stored as ‘American/Chicago’ instead of ‘Central’. Both types are stored in address record, but the ‘shorthand’ version - used for display - was not being set correctly. This meant any update at reverifying was attempting to convert the timezone from ‘American/New_York’ to ‘Eastern’, but the system prevents changes. The root issue was in the site registration/signup process.

resolutions

  • php artisan fix:dd-447-timezone This resets known ‘bad’ timezone data to the correct timezone data
  • Patch RegisterNewClient to use correct timezone label in address record
  • Patch AddressService::relateAddressTimezoneToSite method to provide a default value

steps

artisan console command was put on to live system, and run manually. Timezone identifiers were patched, and new address verification steps were run by hand for the two hospitals in question.

update 3/7/22

this fix was incorrect, because ‘registerNewClient’ action overwrites the site timezone with the wrong information later on. The original setting is correct, but it’s overwritten with ‘address’ timezone, which used to be correct when the address timezone was incorrect. Fixing one broke the other.

Updated with RegisterNewClient test that just checks site timezone.