What type of bug is this?

Incorrect result

What subsystems are affected?

Storage Engine

Minimal reproduce step

Creates a table with fulltext index

CREATE TABLE IF NOT EXISTS `test_cache` (
  `timestamp` TIMESTAMP(9) NOT NULL DEFAULT current_timestamp(),
  `message` STRING NULL NULL FULLTEXT INDEX WITH(analyzer = 'English', backend = 'bloom', case_sensitive = 'false'),
  TIME INDEX (`timestamp`),
)
ENGINE=mito
WITH(
  append_mode = 'true',
);

Inserts rows with unique timestamps and messages for more than 1 row group.

Queries with matches_term in the following step:

• Runs a query that only selects a row group (by timestamp) but doesn't match any message
• Runs a query with another time range and matches some messages
• Runs a query with the same time range as the second query but uses like.

What did you expect to see?

The first query returns 0 rows, the second and third queries return the same number of rows.

What did you see instead?

The second query also returns 0 rows.

What operating system did you use?

Unrelated

What version of GreptimeDB did you use?

0.14.4

Relevant log output and stack trace

SELECT count(*) FROM public."test_cache" where timestamp >= '2025-06-23 22:00:00' and timestamp < '2025-06-23 22:00:09' and  matches_term(message, '<some-trace-id>');
+----------+
| count(*) |
+----------+
|        0 |
+----------+
1 row in set (0.05 sec)

SELECT count(*) FROM public."test_cache" where timestamp >= '2025-06-23 21:57:29' and timestamp < '2025-06-23 22:12:29' and  matches_term(message, '<some-trace-id>');
+----------+
| count(*) |
+----------+
|        0 |
+----------+
1 row in set (0.06 sec)

SELECT count(*) FROM public."test_cache" where timestamp >= '2025-06-23 21:57:29' and timestamp < '2025-06-23 22:12:29' and message like '%<some-trace-id>%';
+----------+
| count(*) |
+----------+
|       39 |
+----------+
1 row in set (0.77 sec)