Change Details

Now that we have both `isInvalidSidebarSource` and `isInvalidPinSource`, it makes sense to make the checks in `fetchDerivedMessages` more specific. Rather than simply filtering out message types generically, we'll handle it more specifically with 1) checking the message type and 2) calling either `isInvalidSidebarSource` or `isInvalidPinSource` accordingly. Once again, there's a `FlowFixMe` for the same reasion as in D9537 -- Flow doesn't refine the types if I don't explicitly `invariant` on all of the unexepcted message types, and that list can either get long or just generally defeats the purpose of moving the logic into message specs to have one single source of truth. Resolves https://linear.app/comm/issue/ENG-5218/refactor-fetchderivedmessages-to-call-isinvalidsidebarsource-or Depends on D9537

Now that we have both `isInvalidSidebarSource` and `isInvalidPinSource`, it makes sense to make the checks in `fetchDerivedMessages` more specific. Rather than simply filtering out message types generically, we'll handle it more specifically with 1) checking the message type and 2) calling either `isInvalidSidebarSource` or `isInvalidPinSource` accordingly. Once again, there's a `FlowFixMe` for the same reason as in D9537 -- Flow doesn't refine the types if I don't explicitly `invariant` on all of the unexpected message types, and that list can either get long or just generally defeats the purpose of moving the logic into message specs to have one single source of truth. Resolves https://linear.app/comm/issue/ENG-5218/refactor-fetchderivedmessages-to-call-isinvalidsidebarsource-or Depends on D9537

Now that we have both `isInvalidSidebarSource` and `isInvalidPinSource`, it makes sense to make the checks in `fetchDerivedMessages` more specific. Rather than simply filtering out message types generically, we'll handle it more specifically with 1) checking the message type and 2) calling either `isInvalidSidebarSource` or `isInvalidPinSource` accordingly. Once again, there's a `FlowFixMe` for the same reasion as in D9537 -- Flow doesn't refine the types if I don't explicitly `invariant` on all of the unexeppected message types, and that list can either get long or just generally defeats the purpose of moving the logic into message specs to have one single source of truth. Resolves https://linear.app/comm/issue/ENG-5218/refactor-fetchderivedmessages-to-call-isinvalidsidebarsource-or Depends on D9537