-
Notifications
You must be signed in to change notification settings - Fork 15
Description
Steps to reproduce:
Original issue: see https://github.com/vrogach2020/mdm-sandbox/pull/1
Given the following setup: a Cartridge application + tarantool/crud + tarantool/migrations + integration tests in luatest, an integration test trying to call crud.insert('test', {...})
fails with error Failed to insert test, error: Insert: Space "test" doesn't exist
, although the space is initialized from migrations and does exist at the time of call, which is checked beforehand with a code like:
--wait until migrations are applied
for _, server in pairs(helper.cluster.servers) do
--spaces may be created with a slight delay on replicas
helper.cluster:retrying({ timeout = 1 }, function()
t.assert_not(server.net_box:eval('return box.space.test == nil'), server.alias)
end)
end
helper.cluster:wait_until_healthy()
CRUD checks the space existence before performing operations on it using internal vshard connections, the simplified code looks like :
_, replicaset = next(vshard.router.routeall())
replicaset.master.conn.space[space_name]
Investigated by @rosik:
Vshard connection is established before migrations, and until the first insert, there are no other communications. Thus crud uses outdated schema and the request fails.
The suggested W/A is explicitly calling ping()
for forcing schema update:
helper.cluster.main_server.net_box:eval([[
local vshard = require('vshard')
for _, r in pairs(vshard.router.routeall()) do
r.master.conn:ping()
end
]])
Actual result
CRUD may fail to work with spaces if vshard schema in internal connections is outdated, returning a fake "space doesn't exist" error
Expected result
CRUD doesn't fail to work with spaces when spaces actually exist
Proposed solution
-
@racktear: do not check for space existence at all.
May lead to errors when attempting to use the space format/metadata. -
Do not use vshard connections for checking the space existence.
Probably requires the cluster DDL to be implemented