TECH TASK: refactor `hotlineMessages.findMemberPhoneNumber`
context
- when trying to
REPLY
to a hotline message id or BAN
it, we need to do something if the hotline message we are trying to look up is either invalid (not a number), has been deleted, or never existed
- right now, we handle that rather crudely by rejecting a promise when
hotlineMessageRepository.findMemberPhoneNumber
finds no hotline message record matching the id passed to it.
- this creates problems when trying to distinguish between these cases or between this and a generic database error. see here for an example
- above, we opted to introduce a custom error type to enable us to distiguish the cause of the error. in this MR, we would like to return
null
instead, as a more idiomatic alternative that allows for a slightly cleaner control flow
implementation changes
- return
null
if no hotline message found
- modify
execute#replyToHotlineMessage
and execute#banMember
to accomodate this change
desired behavior (stub)
- behavior should remain the same. (ie: if i try to BAN or REPLY to a non-existent hotline message id, i get an error)
- if we're feeling stretch-goal-y: the error message is currently a bit confusing. (it uses the
invalidMessageId
message which refers to an "invalid hotline message ID" in both the case where the parse layer produced an error for BAN foo
and in the case where the execute
layer could not find a hotline message.) it would be nice to make a nonExistentMessageId
messagea and use it here instead!