bug: create sink into table encounters "table is in altering procedure"

[yezizp2012]

Describe the bug

version: v2.0.2

Typically, when two concurrent DDLs(schema change or sink into table) target the same table, the error message should be "table version is stale". The issue likely stems from an inconsistency in the in-memory status, which can only be resolved by restarting the meta node. I guess it might be another corner case where creation of a sink into the table fails.

Error message/log

No response

To Reproduce

No response

Expected behavior

No response

How did you deploy RisingWave?

No response

The version of RisingWave

No response

Additional context

No response

[yezizp2012]

After reviewing the code and investigate again, I found that these two errors are both normal and reasonable. They will occur under different race condition situations.

risingwave/src/meta/src/manager/catalog/mod.rs

Lines 3809 to 3817 in 45db829

	// Check whether the frontend is operating on the latest version of the table.
	if table.get_version()?.version != original_table.get_version()?.version + 1 {
	bail!("table version is stale");
	}
	// TODO: Here we reuse the `creation` tracker for `alter` procedure, as an `alter` must
	// occur after it's created. We may need to add a new tracker for `alter` procedure.
	if database_core.has_in_progress_creation(&key) {
	bail!("table is in altering procedure");

Examples:

1. in case 1, when meta receives the request for ddl-1 to perform a version check, if the barrier of ddl-0 has already been completed with the version updated and hasn't been synchronized to the frontend yet, the version check will reject ddl-0.

2. in case 2, when meta receives the request for ddl-1, but ddl-0 has not been completed, for example when the barrier latency is very high, at this point, ddl-1 will pass the version check, but will be rejected by the table status check.