Yeah, I agree it's kind of risky.

Having main function determine time filter info

Another approach would be to rename messageSelectionCriteriaToSQLClause (to eg. parseMessageSelectionCriteria) and have it return { +sqlClause: SQL, +timeFilterData: TimeFilterData }. TimeFilterData would contain the information necessary for messageSelectionCriteriaHasTimeFilterForThread to determine an answer without looking at MessageSelectionCriteria.

The complexity here is that TimeFilterData would not be simple. It would need to be something like:

type TimeFilterData =
  | { +globalTimeFilter: true }
  | { +globalTimeFilter: false, +threadSpecificTimeFilter: $ReadOnlySet<string> };

The logic for determining TimeFilterData might be somewhat brittle, although it's probably less brittle than the current approach.

Your suggestion of adding an invariant

I'm a bit worried about adding an invariant for this sort of thing... it's technically correct (the invariant should never trigger unless the programmer made a mistake), but it seems somewhat likely that we would fail to trigger the invariant in testing and it would get triggered in production, which would be a negative user experience.

I'll look into my solution above first, and if it doesn't work I'll add an invariant.