Repository navigation
fix(api): guard contacts without a usual place of residence on the follow-up dashboard - #19
Merged
lbrunofidelis merged 1 commit intoSep 1, 2026
Conversation
The follow-up dashboard crashed with a 500 whenever a contact had addresses but none of them was a usual place of residence, which is possible for contacts that only carry a notification address.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
The follow-up dashboard returns a 500 and never loads:
Root cause
In
FollowUp.getOrCountGroupedByPerson, the record post-processing looks up the contact's usual place of residence withaddresses.find(...)and dereferences.locationIdon the result, guarded only byaddresses.length > 0. When a contact has addresses but none of them is a usual place of residence,findreturnsundefinedand the request blows up. This happens on both passes: while collecting the location ids and while attaching the resolved locations.Those lines are original Go.Data code and were never touched here. What started triggering them is the notification address type, which lets a contact exist with a notification address and no usual place of residence. Every other place in the codebase that resolves the usual place of residence already handles the missing address; only these two did not.
Fix
Check the lookup result before reading
locationId, matching the pattern already used elsewhere in the codebase. Contacts without a usual place of residence are now listed without a resolved location instead of breaking the whole request.Verification
Reproduced against a local database holding a contact whose only address is a notification address and who owns the outbreak's only follow-up, by calling the method the same way the remote method does.
Before the fix:
After the fix, on the same data plus a seeded contact that does have a usual place of residence:
Contacts with a usual place of residence still get their location resolved.
npm run lintpasses on the changed file.