I'm seeing the following race occasionally in alter_table-randomized-test:
- a follower tablet is shutting down while some operations are pending. The first operation is an ALTER_TABLE, and the second is a WRITE which depends on the ALTER (i.e includes the new column)
- we cancel the ALTER successfully, and then the thread gets de-scheduled
- the PrepareTask for the WRITE runs before we're able to cancel it. It then fails to prepare because the alter it depends on has not completed
It seems like we should probably cancel the pending operations in reverse order.