Yeah! that would be temporary avoiding it.
We can temporarily fix it by triggering a full backup every time someone does a DROP_* operation.
But, we want the fix for this issue to go in 20.11, so we should have a permanent fix in some time.
yes, every proposal is written in RAFT WAL. But, the contents of the proposal determine what should be written to badger, and the contents of badger determine what goes in backup. This particular proposal for DROP_ALL dictates that the contents of badger be emptied. Since, there is nothing left in badger after this operation, so nothing goes in the second backup and while restoring the old data is restored from the first full backup.
Basically, at present we are not recording during backup that such an operation has occurred, and so we are not able to construct exact replica during restore.
we will disallow that.