After WT-15800, we stop truncating the history store on the standby for layered table drop. There is an edge case that I'm worried about. We may never truncate the history store if the standby steps up and becomes the primary. The sequence is like this:

• The standby picks up a checkpoint that doesn't include the table drop (the drop has happened on the primary but hasn't been checkpointed).
• The standby replays the oplog to drop the table and it skips truncating the history store.
• The standby steps up as the primary.

I'm not sure in this case, will we replay the oplog again to drop the table so that we can clear the history store? If not, the history store content for that table is never truncated.

It is mostly a manageable problem because the history store content will be obsolete as the global timestamp moves. However, if we have a history store record that doesn't have a valid stop timestamp (because of prepared updates), we may truly leak space in the history store and the history store validation will fail. In addition, if we reuse the btree id for the dropped table (I believe we don't do that), the content in the history store will come back to life.