There is a confusion in resolv after_frag between slot and block height.
Example: A transaction received during slot S referencing the blockhash of slot S-153 should not expire if 4 slots were skipped in-between (which is common), because the block height difference is 149 only.
The result is that many transactions are wrongly ignored by a leader if there were skips during last 151 slots.

The offending code.

A similar check is done in pack, but this time including some arbitrary margin to cope with block height/slot difference.

• A simple fix would be to replace 151 in resolv with this TRANSACTION_LIFETIME_SLOTS constant, but it's not satisfactory.

• I would personally remove these imperfect expiration checks in both resolv and pack and rely only on checks done in bank.
  If these checks are security barriers, then they don't hold long. An attacker could clutter pack with transactions that won't land using other ways. During normal operation, transactions not being forwarded anymore, the number of expired txs is not high.

• Another option is to have bank send the true block height along with the block hash and use it for expiration checks.

If you are interested, I can post a PR implementing the option you think is best.