Data loss during concurrent inserts and repartition

[WenyXu]

What type of bug is this?

Incorrect result

What subsystems are affected?

Distributed Cluster

Minimal reproduce step

When running ALTER TABLE ... MERGE/SPLIT PARTITION (repartition) on a partitioned table, concurrent inserts during the repartition process may result in missing rows.
In fuzz testing, inserts with sequential timestamps were continuously generated, but after repartition finished, querying the table showed gaps in the time index, indicating that some inserted data was likely dropped during repartition.

1. Create a partitioned table:

CREATE TABLE et (
  voluptatibus DOUBLE,
  molestias TIMESTAMP(6) TIME INDEX,
  eT SMALLINT NOT NULL,
  consequaTur DOUBLE,
  ACcUSanTIUM DOUBLE,
  PRIMARY KEY(voluptatibus)
)
ENGINE=mito
PARTITION ON COLUMNS(voluptatibus) (...);

2. Start repartition by merging partitions:

ALTER TABLE et MERGE PARTITION (...);

3. While repartition is ongoing, continuously insert rows with sequential timestamps:

INSERT INTO et (...) VALUES
('2026-02-06 10:44:20.597', ...),
('2026-02-06 10:44:21.597', ...),
('2026-02-06 10:44:22.597', ...),
...

4. Query the timestamp:

SELECT molestias FROM et ORDER BY molestias;

What did you expect to see?

• Inserts executed during repartition should not be lost.
• Query results should contain all inserted timestamps continuously.

What did you see instead?

After repartition + concurrent inserts:

• Some timestamps are missing in query results.
• This suggests that writes happening during repartition may be dropped or not persisted correctly.

What operating system did you use?

doesn't matter

What version of GreptimeDB did you use?

main

Relevant log output and stack trace

[killme2008]

Is this in the case where the INSERT returns success? If the INSERT fails, then it wouldn’t be a data-loss scenario. @WenyXu

[WenyXu]

Is this in the case where the INSERT returns success?

Yes