DatabaseTermIdsResolver has a logic that supports falling back to reading from master in case the resolved terms from replica do not cover all the ids that the user has asked for.
Such a case can happen in one of two situations:
- the ids to be resolved were fetched from master, and the linked terms hasn't been replicated yet
- the ids to be resolved were fetched from replica, and the linked terms hasn't been replicated yet
The first one we have judged has no real use-case that we are aware of. A user that is trying to resolve term ids using that resolver must have also fetched the ids from replica in the first place, as we do not usually read from master unless explicitly specified or as part of write logic.
The second case is very unlikely to hit as replication of item/property terms will be quickly followed by replication of any related terms, if not preceded as terms are written to term store before property/item terms are linked to them.
So the conclusion was to remove this fallback logic as it simplifies the implementation, and allows a cleaner and more straight forward implementation of filtering logic (where this issue was discovered) as described in T225003.