I will add some detail to barton26's comments. A number of testers including myself did numerous, and I mean numerous sync from zeroes and sync from snapshots in the course of the run up to the 3.7.8.0 and 3.7.9.0 releases to shake the bugs out. This particular error got by us because it is a very subtle timing problem relating to the validation of beacons.

Beacons are only valid for 6 months from when advertised in a beacon transaction. They can be (and are usually auto) renewed at 5 months.

When a node is in sync and stakes a block and it is communicated to the other nodes the receiving nodes evaluate the block to see if it can be accepted. The nodes use local node time to do this, and in this situation the block height time is essentially equivalent to local client time, with some very minor slop.

That is not the case during a sync. During a sync, when the client evaluates accepting a block that was, say, two months back, the current time of the client is two months in the future compared to the time of the block. This is where the problem was. A test for beacon expiration during sync was using the current client (local) time, instead of the time of the block staking. If the beacon expired between the block time and the current time, the test using (incorrectly) local time then caused the beacon to be treated as expired... leading to an incorrect calculation of research reward and a rejection of the block... leading to the problem we were having. As time diverged more and more from the release of 3.7.8.0, more and more beacons were starting to fall into this time difference... causing new sync errors to crop up.

This is now repaired and we have tested sync from zero and sync from various snapshots on mainnet and everything appears good.