The subscription doesn't appear to be handling the vnode bitmap update correctly.

[shanicky]

Describe the bug

commit d0f8e58

./risedev p

run sql

dev=> create table t(v int);
CREATE_TABLE
dev=> create subscription subscription1 from t with (retention = '1D');
CREATE_SUBSCRIPTION
dev=> alter table t set parallelism = 1;

It could lead to a panic.

2024-04-06T19:06:29.940053+08:00  INFO      rw-main risingwave_meta::barrier::state: update paused state current=Some(ConfigChange) new=None
thread 'rw-streaming' panicked at src/storage/src/hummock/store/local_hummock_storage.rs:451:9:
There is uncommitted staging data in read version table_id TableId { table_id: 3 } instance_id 2 on vnode bitmap update

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

[hzxa21]

It is because subscription will write to state store on seeing a barrier even after pause:

risingwave/src/stream/src/common/log_store_impl/subscription_log_store.rs

Line 90 in 436884a

for vnode in self.serde.vnodes().iter_vnodes() {

Discussed offline with @xxhZs. It will be fixed in #15180

[shanicky]

It is because subscription will write to state store on seeing a barrier even after pause:

risingwave/src/stream/src/common/log_store_impl/subscription_log_store.rs

Line 90 in 436884a

for vnode in self.serde.vnodes().iter_vnodes() {

Discussed offline with @xxhZs. It will be fixed in #15180

Can we make it in time for the 1.8.1 release?

[hzxa21]

We can hotfix it in main/release-1.8 but subscription is an unreleased feature so no user should be using it. So I think it is okay to not block 1.8.1. Is the assertion caught by CI tests?

[xxhZs]

test it , fixed