Atomicity of space:drop()

[mkostoevr]

Bug description

box.schema.space.drop can leave the database in an inconsistent state if one of its steps failed.

• OS: Linux
• OS Version: Ubuntu 22.04.2 LTS
• Architecture: amd64

Tarantool version: current HEAD (as of 17 may 2023).

Steps to reproduce

1. Configure the tarantool box: box.cfg{}.
2. Attempt to drop _vpriv system space (will fail): box.space._vpriv:drop().
3. Attempt to drop _vinyl_deferred_delete (should fail by the same reason, but... see below): box.space._vinyl_deferred_delete:drop().

Actual behavior

tarantool> box.space._vpriv:drop()
---
- error: Can't drop the primary key in a system space, space '_vpriv'
...

tarantool> box.space._vinyl_deferred_delete:drop()
---
- error: 'builtin/box/schema.lua:230: attempt to index field ''object'' (a nil value)'
...

Expected behavior

The first error is expected, but the second one is not.

Root cause

1. On attempt to drop the _vpriv we drop all of its indexes starting from non-primary ones here: box.schema.space.drop+25, so the space has no indexes anymore.
2. Then we try to get its object index on _vinyl_deferred_delete drop here: box.schema.space.drop+27->revoke_object_privs+3. But since we have deleted all non-primary indexes of the _vpriv before, tarantool fails with nil-access error.

Proposal

The box.schema.space.drop function should revert all the changes it made if any step is failed.

[olegrok]

Seems it's related to #4348

In case if drop will be atomic we have following case

tarantool> box.atomic(function() box.space._vpriv:drop() end)
---
- error: Can't drop the primary key in a system space, space '_vpriv'
...

tarantool> box.atomic(function() box.space._vinyl_deferred_delete:drop() end)
---
...

[mkostoevr]

Seems it's related to #4348

Yes, it is.

In case if drop will be atomic we have following case

tarantool> box.atomic(function() box.space._vpriv:drop() end)
---
- error: Can't drop the primary key in a system space, space '_vpriv'
...

tarantool> box.atomic(function() box.space._vinyl_deferred_delete:drop() end)
---
...

Yes, and the behavior is desirable. Now you can drop the _vinyl_deferred_delete space, but it will be fixed if the related PR (#8623) will be merged.

Closed the issue as duplicate of #4348.