In case insert_many, insert_object_many, replace_many, replace_object_many, upsert_many or upsert_object_many has been called on a space with custom sharding info and every tuple/object in the request had bucket_id, ShardingHashMismatchError has been returned even though there are no issues with sharding info. For example, some users met this issue while working with tt-ee tt crud import command.
The reason is as follows. To ensure sharding info consistency between the storage and the router, some metainfo is calculated for a request in case bucket_id is generated. In case no bucket_id is generated, no sharding info is passed and consistency check is skipped (since it is not needed). Before this patch, *_many operations haven't skipped consistency check when it was expected due to improper skip_sharding_hash_check flag setup.
In case
insert_many,insert_object_many,replace_many,replace_object_many,upsert_manyorupsert_object_manyhas been called on a space with custom sharding info and every tuple/object in the request hadbucket_id,ShardingHashMismatchErrorhas been returned even though there are no issues with sharding info. For example, some users met this issue while working with tt-eett crud importcommand.The reason is as follows. To ensure sharding info consistency between the storage and the router, some metainfo is calculated for a request in case bucket_id is generated. In case no bucket_id is generated, no sharding info is passed and consistency check is skipped (since it is not needed). Before this patch,
*_manyoperations haven't skipped consistency check when it was expected due to improperskip_sharding_hash_checkflag setup.Closes #437
I didn't forget about