Crud errors after space drop in migrations

[iDneprov]

If you call box.space.space_name:drop() in migrations. Then during operations applied to other spaces on crud 0.10.0 and newer an error appears.
If you change crud version to 0.9.0, everything works again.

Reproducer

Error example:

localhost:3301> crud.select('trm_1')
---
- null
- line: 181
  class_name: CallError
  err: 'Failed for 275e2b29-64ba-470e-9a4e-18153132f465: Function returned an error:
    {"base_type":"LuajitError","type":"LuajitError","message":"...are\/tarantool\/crud\/common\/sharding\/sharding_metadata.lua:61:
    attempt to index a nil value","trace":[{"file":"\/opt\/actions-runners\/sdk_01\/_work\/sdk\/sdk\/tarantool-2.8\/src\/lua\/utils.c","line":449}]}'
  file: '...ktop/vtb-dws/.rocks/share/tarantool/crud/common/call.lua'
  stack: "stack traceback:\n\t...ktop/vtb-dws/.rocks/share/tarantool/crud/common/call.lua:181:
    in function 'any'\n\t...are/tarantool/crud/common/sharding/sharding_metadata.lua:97:
    in function <...are/tarantool/crud/common/sharding/sharding_metadata.lua:90>\n\t[C]:
    in function 'pcall'\n\t...are/tarantool/crud/common/sharding/sharding_metadata.lua:37:
    in function '_fetch_on_router'\n\t...are/tarantool/crud/common/sharding/sharding_metadata.lua:133:
    in function 'fetch_sharding_key_on_router'\n\t...dws/.rocks/share/tarantool/crud/select/compat/select.lua:63:
    in function 'func'\n\t...op/vtb-dws/.rocks/share/tarantool/crud/common/schema.lua:88:
    in function 'wrap_func_reload'\n\t...dws/.rocks/share/tarantool/crud/select/compat/select.lua:288:
    in function <...dws/.rocks/share/tarantool/crud/select/compat/select.lua:251>\n\t[C]:
    in function 'pcall'\n\t...dws/.rocks/share/tarantool/crud/common/sharding/init.lua:163:
    in function <...dws/.rocks/share/tarantool/crud/common/sharding/init.lua:158>\n\t[C]:
    in function 'xpcall'\n\t...neprov/Desktop/vtb-dws/.rocks/share/tarantool/errors.lua:145:
    in function <...neprov/Desktop/vtb-dws/.rocks/share/tarantool/errors.lua:139>\n\t[C]:
    in function 'pcall'\n\tbuiltin/box/console.lua:402: in function <builtin/box/console.lua:378>\n\t[C]:
    at 0x0109c56660"
  str: 'CallError: Failed for 275e2b29-64ba-470e-9a4e-18153132f465: Function returned
    an error: {"base_type":"LuajitError","type":"LuajitError","message":"...are\/tarantool\/crud\/common\/sharding\/sharding_metadata.lua:61:
    attempt to index a nil value","trace":[{"file":"\/opt\/actions-runners\/sdk_01\/_work\/sdk\/sdk\/tarantool-2.8\/src\/lua\/utils.c","line":449}]}'
...

[no1seman]

+1 If any space dropped - crud 0.10.0+ fails to work with the same error. Seems that there is a problem in triggers on box.space._space

[DifferentialOrange]

At the first glance, it seems that the reason is that space is dropped, but its sharding info is not cleaned up. So, as a workaround, I suggest you to do a proper ddl space drop.

[no1seman]

yea, right you are but why not add a check that space was dropped and not take any sharding info into account?

It's quite common problem, because ddl and migrations doesn't contain any high level helpers to unregister sharding keys, so nobody do it in real life.

[DifferentialOrange]

yea, right you are but why not add a check that space was dropped and not take any sharding info into account?

It's quite common problem, because ddl and migrations doesn't contain any high level helpers to unregister sharding keys, so nobody do it in real life.

Yes, we will definitely fix it in a patch.

[no1seman]

Here is an example of consequences of our API: https://t.me/tarantoolru/188981

User can't clean __ddl_sharding_key and thus can't continue to use crud

[DifferentialOrange]

Here is an example of consequences of our API: https://t.me/tarantoolru/188981

User can't clean __ddl_sharding_key and thus can't continue to use crud

Yeah, I already saw that one. Refer to #310 ticket. Solutions for this issue and #310 one are already prepared. After review, we will merge them to master and publish a bugfix release 0.12.1 (it shouldn't be too long).