Integration tests are not stable

[ygf11]

Describe this problem

For create table test,

https://github.com/CeresDB/ceresdb/blob/25557c73adaa6815875aaea3ccd5b61bf54e291f/tests/cases/local/05_ddl/create_tables.sql#L64

it will report error like:

Failed to execute query, err: Server(ServerError { code: 500, msg: "Failed to execute interpreter, query: CREATE TABLE `05_create_tables_t8`(c1 int, t1 timestamp NOT NULL TIMESTAMP KEY) ENGINE = Analytic with (storage_format= 'unknown');. Caused by: Failed to execute create table, err:Failed to create table, name:05_create_tables_t8, err:Failed to create table, err:Invalid arguments, err:Invalid options, space_id:2, table:05_create_tables_t8, table_id:2199023255725, err:Unknown storage format. value:\"unknown\"." })

The table_id in error message is not stable in my local pc, it will change if I run tests again.

The issue maybe is in test config, we use Local storage as the server config for integration tests now.

cc: @waynexia @jiacai2050

Steps to reproduce

Run tests again.

Expected behavior

The output should the same as before when we rerun tests.

Additional Information

No response

[jiacai2050]

Yeah, it's already reported in https://github.com/CeresDB/ceresdb/issues/114#issuecomment-1218949297

For your case, you can ignore this error for now, we will support special interceptor to replace those random string in near future(maybe one month I guess).

[ygf11]

For your case, you can ignore this error for now, we will support special interceptor to replace those random string in near future(maybe one month I guess).

Thanks, got it.

[ShiKaiWi]

#270 will fix this. The reason for this bug is that the test data won't be cleaned before any run, while the table id is auto-incremented, so the created, dropped, created-again table may have different table ids every time run the tests.

[jiacai2050]

I think of one corner case even when #270 is merged

if users drop a new table in 00_dummy, then all table id after 00_dummy will be affected

So an interceptor may also need to deal with this case.

[ShiKaiWi]

I think of one corner case even when #270 is merged

if users drop a new table in 00_dummy, then all table id after 00_dummy will be affected

So an interceptor may also need to deal with this case.

Actually, just update the result files if the test cases are modified.

[jiacai2050]

It may be a little annoying since those other files are not touched.

Fow now I think it's OK to update those files manually since there are not many table ids in our testcases, but I prefer to keep the ability to replace something before diff.

[ShiKaiWi]

I guess #270 has fixed this, so let's close it.