Fuzz insert test failed

[WenyXu]

What type of bug is this?

Unexpected error

What subsystems are affected?

Storage Engine

Minimal reproduce step

1. Hard code the FuzzInput to

FuzzInput { seed: 266, columns: 19, rows: 3995 }

2. Run GreptimeDB
3. Run

cargo fuzz run --fuzz-dir tests-fuzz -D --sanitizer=none fuzz_insert 

OR

CREATE TABLE `teMpora`(
  `raTione` TIMESTAMP(0) TIME INDEX,
  `exPLICABO` FLOAT DEFAULT 0.7750273,
  aut BOOLEAN NULL,
  `QUiA` BOOLEAN,
  `quI` BIGINT NULL,
  `nEscIunt` BIGINT NOT NULL,
  `REICIENdIS` INT NULL,
  `noBis` BIGINT DEFAULT -1522150256160686140,
  `CUmQUE` INT DEFAULT -1268285913,
  `quOS` BIGINT DEFAULT 6724805839282901890,
  odio FLOAT,
  `DOlOREM` BOOLEAN,
  et INT NOT NULL,
  `LIbero` INT,
  `QUis` FLOAT DEFAULT 0.4887722,
  `MiNIMA` FLOAT,
  tempora SMALLINT,
  rem INT NOT NULL,
  `Ea` FLOAT DEFAULT 0.57261616,
  PRIMARY KEY(`LIbero`, tempora, `DOlOREM`, `QUiA`)
) ENGINE = mito;

INSERT INTO
  `teMpora`
VALUES
  (
    '2037-06-27 09:54:36+0000',
    0.3343737,
    false,
    false,
    -4144725995123210844,
    -3082176640087399360,
    1020303571,
    NULL,
    957236357,
    5685825137374556496,
    0.51182777,
    false,
    -108127605,
    240702623,
    0.259059,
    NULL,
    -11743,
    1769219856,
    0.19971871
  );

SELECT
  `raTione`,
  `exPLICABO`,
  aut,
  `QUiA`,
  `quI`,
  `nEscIunt`,
  `REICIENdIS`,
  `noBis`,
  `CUmQUE`,
  `quOS`,
  odio,
  `DOlOREM`,
  et,
  `LIbero`,
  `QUis`,
  `MiNIMA`,
  tempora,
  rem,
  `Ea`
FROM
  `teMpora`
ORDER BY
  `raTione`

What did you expect to see?

Should pass the test

What did you see instead?

...
2024-05-21T06:57:09.5460417Z fuzz test must be succeed: 0: Failed to assert: Expected value: 0.3343737, got: NULL, at /home/runner/work/greptimedb/greptimedb/tests-fuzz/src/validator/row.rs:137:13
...

https://github.com/GreptimeTeam/greptimedb/actions/runs/9170138785/job/25211918959?pr=3998

What operating system did you use?

doesn't matter

What version of GreptimeDB did you use?

main

Relevant log output and stack trace

No response

[WenyXu]

However, I didn't reproduce the bug in the standalone mode.

[WenyXu]

And another failure is reported: https://github.com/GreptimeTeam/greptimedb/actions/runs/9171698235/job/25216790287

Failing input:

	FuzzInput {
	    seed: 20974090,
	    columns: 25,
	    rows: 3433,
	}

[WenyXu]

However, I didn't reproduce the bug in the standalone mode.

I reproduced the bug by:

1. Hard code the FuzzInput

FuzzInput { seed: 266, columns: 19, rows: 3995 }

2. Run GreptimeDB
3. Run

cargo fuzz run --fuzz-dir tests-fuzz -D --sanitizer=none fuzz_insert 

The problem is:

mysql> SELECT   `raTione`,   `exPLICABO`,   aut,   `QUiA`,   `quI`,   `nEscIunt`,   `REICIENdIS`,   `noBis`,   `CUmQUE`,   `quOS`,   odio,   `DOlOREM`,   et,   `LIbero`,   `QUis`,   `MiNIMA`,   tempora,   rem,   `Ea` FROM   `teMpora` WHERE `raTione` >= '2037-06-27 09:54:36+0000' ORDER BY  `raTione` LIMIT 3; 
+---------------------+-----------+------+------+----------------------+----------------------+-------------+---------------------+-------------+----------------------+------------+---------+------------+-------------+------------+------------+---------+------------+------------+
| raTione             | exPLICABO | aut  | QUiA | quI                  | nEscIunt             | REICIENdIS  | noBis               | CUmQUE      | quOS                 | odio       | DOlOREM | et         | LIbero      | QUis       | MiNIMA     | tempora | rem        | Ea         |
+---------------------+-----------+------+------+----------------------+----------------------+-------------+---------------------+-------------+----------------------+------------+---------+------------+-------------+------------+------------+---------+------------+------------+
| 2037-06-27 09:54:36 | 0.3343737 |    0 |    0 | -4144725995123210844 | -3082176640087399360 |  1020303571 |                NULL |   957236357 |  5685825137374556496 | 0.51182777 |       0 | -108127605 |   240702623 |   0.259059 |       NULL |  -11743 | 1769219856 | 0.19971871 |
| 2037-06-27 09:54:36 |      NULL |    0 |    1 | -8512579083037740436 | -6317361602420138257 |        NULL | 8553791454907064599 |  -191878569 | -5849261073571716798 | 0.47257352 |       0 | 1893334465 | -1929143043 | 0.43160588 |       NULL |    NULL | -613283531 | 0.65436834 |
| 2037-07-14 06:31:33 |      NULL |    1 |    0 | -2603303141915165490 |   179325994161471244 | -1442948163 | 8772107029952948245 | -1327411896 |                 NULL | 0.44200462 |       1 | -190003556 |  1560091763 |   0.596828 | 0.33098477 |    NULL | -690908885 |  0.2929886 |
+---------------------+-----------+------+------+----------------------+----------------------+-------------+---------------------+-------------+----------------------+------------+---------+------------+-------------+------------+------------+---------+------------+------------+

[WenyXu]

@CookiePieWw Would you have any idea? Maybe we should sort the timestamp column + primary columns

[CookiePieWw]

@CookiePieWw Would you have any idea? Maybe we should sort the timestamp column + primary columns

Maybe sort them with just primary keys is enough. The failure happens when there's the same timestamp and primary keys cannot be same. I wrongly took the timestampe columns as primary keys here before. Will make some changes later.

[WenyXu]

The failure happens when there's the same timestamp and primary keys cannot be same.

Maybe we still need to sort with the timestamp column (i.g., sort with primary keys + timestamp )? For instance:

__ primary __ | ts | _value_
a, b, c, d, e, ts, v1, v2, v3
0, 0, 0, 0, 0, 1, 1, 2, 3
0, 0, 0, 0, 0, 0, 1, 2, 3
0, 0, 0, 0, 0, 3, 1, 2, 3

[CookiePieWw]

Ah you're right. The time index and primary keys uniquely define a row, instead of the primary keys only.

[WenyXu]

Ah you're right. The time index and primary keys uniquely define a row, instead of the primary keys only.

Yes. Would you mind helping us fix this bug👀

[CookiePieWw]

Yes. Would you mind helping us fix this bug👀

Sure, already working on it :)

[WenyXu]

Yes. Would you mind helping us fix this bug👀

Sure, already working on it :)

Thanks!❤️