Wait, but shouldn't these transactions be valid either way if you had their parents in your mempool already?
While briefly staring at my mempool, I noticed that some transactions got rejected because their locktime was based on a freshly mined block, which my node hadn't seen yet. Even several minutes later my mempool doesn't have it.
nostr:npub18d4r6wanxkyrdfjdrjqzj2ukua5cas669ew2g5w7lf4a8te7awzqey6lt3 did pick it up, presumably because it saw the block earlier? https://mempool.space/tx/8c235cb0eb540ed75aeebca5d3beeb0c0d968b8590b1ddf31ed87f997e2ea3b8
I wonder if it gets added later as other peers tell me about it again.
Discussion
I think I linked to the wrong example. Though it's a similar phenomena. This one got rejected for being in a too large unconfirmed chain:
2023-08-18T09:27:32.705237Z [net] got inv: wtx 8c235cb0eb540ed75aeebca5d3beeb0c0d968b8590b1ddf31ed87f997e2ea3b8 new peer=50
2023-08-18T09:27:32.706424Z [net] Requesting wtx 8c235cb0eb540ed75aeebca5d3beeb0c0d968b8590b1ddf31ed87f997e2ea3b8 peer=50
2023-08-18T09:27:33.912485Z [mempoolrej] 8c235cb0eb540ed75aeebca5d3beeb0c0d968b8590b1ddf31ed87f997e2ea3b8 from peer=50 was not accepted: too-long-mempool-chain, too many descendants for tx cca29e4a3f560b3414e47feede6de0c2d9cb94af535780479e531f14bd003395 [limit: 25]
The chain was too long from the point of view of my node, because it hadn't seen the confirmations yet.