Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Drop counselors with invalid zips when geocoding #8718

Merged
merged 3 commits into from
Jan 16, 2025
Merged

Conversation

wpears
Copy link
Member

@wpears wpears commented Jan 15, 2025

Currently, if when the housing_counselor mgmt command attempts to geocode data with an invalid zipcode, it throws a KeyError. This bails out of the command and thus causes our daily update to fail.

Since we don't control this data, I think it would be better to simply drop the counselor with the invalid zip (while logging that this is being done). This should allow us to be more resilient to erroneous data creeping into the HUD list of counselors.

@wpears wpears force-pushed the drop-invalid-zips branch from 15a1239 to 399b17f Compare January 15, 2025 21:51
@wpears wpears requested review from higs4281 and chosak January 15, 2025 22:01
Copy link
Member

@chosak chosak left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the fix.

logger.warning(f"{zipcode} not in zipcodes")
return False

return True

def geocode_counselor(self, counselor):
counselor = dict(counselor)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can this line be removed since you already ensure the counselor object is a dict in filter_zipcodes?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think so, since the filter just removes entries from the list of counselors but doesn't modify them. I could do this to the whole list ahead of time though

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Did the above in the following two commits

@wpears wpears added this pull request to the merge queue Jan 16, 2025
Copy link
Member

@higs4281 higs4281 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The only thing I wonder about is how information about bad data could make its way back to the source. Seems to be relatively rare, so maybe not a concern.

Merged via the queue into main with commit 6fde49c Jan 16, 2025
12 checks passed
@wpears wpears deleted the drop-invalid-zips branch January 16, 2025 16:41
@mrosemblat
Copy link

The only thing I wonder about is how information about bad data could make its way back to the source. Seems to be relatively rare, so maybe not a concern.

@higs4281 @wpears Could we check to see how often this occurs (or occurred prior to the fix?).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants