psergey, I've updated the description, it appears that it's important to run the test in shm (e.g. with --mem), in addition to previously mentioned options. Could you please try again?

Reproducible, for example on this cset:

commit a7e5049fec3d938dd19df82c3db047a2a0d9119f

Author: Sergei Petrunia <psergey@askmonty.org>

Date:   Tue Apr 17 11:10:11 2018 +0300

It is not yet clear to me what is happening.
Index number 256 is the first "user" index number, it is used for t1's primary key.
{{ALTER TABLE t1 FORCE }} causes a table rebuild, which causes the original table to be renamed and then dropped.
MyRocks' background drop index operation finds all index entries to be totally gone and removes the index description from the data dictionary.
then, compaction filter somehow encounters a row with an old index_nr.

The issue is not reproducible without the XA commands.
I am still at loss what role they play here.

Debug log:

AAA query: SHOW SLAVE STATUS

AAA query: SELECT 'No such row' = 'No such row'

AAA query: call mtr.check_testcase()

AAA query: select @@datadir

AAA query: CREATE TABLE t1 (i INT) ENGINE=RocksDB

AAA query: INSERT INTO t1 VALUES (1)

AAA rocksdb_commit

AAA query: XA START 'xid'

AAA query: INSERT INTO t1 SELECT * FROM t1

AAA rocksdb_commit

AAA query: ALTER TABLE unknown_table

AAA query: ALTER TABLE t1 FORCE

AAA rocksdb_commit

AAA starting DROP INDEX 256

2018-04-17 12:26:33 140529051981568 [Warning] Access denied for user 'unknown_user'@'localhost' (using password: NO)

AAA query: XA END 'xid'

AAA query: XA COMMIT 'xid' ONE PHASE

AAA rocksdb_commit

AAA finished DROP INDEX 256

AAA query: CREATE TABLE t2 ENGINE=RocksDB SELECT 1 AS b

AAA rocksdb_commit

AAA query: DROP TABLE t2

2018-04-17 12:26:33 140529096775424 [ERROR] RocksDB: Could not get index information for Index Number (0,256)

AAA query: set SQL_LOG_BIN=0

AAA query: set WSREP_ON=0

AAA query: set debug_dbug=""

AAA query: use mtr>rocksdb_commit_by_xid

AAA query: set session transaction read write

The behavior changed some time between 10.2.34 and 10.2.44, now ALTER TABLE t1 FORCE in the test case doesn't execute apparently waiting for a lock. I assume it's the expected outcome, at least InnoDB did the same even on 10.2.34.

Closing as "can't reproduce" as I won't bisect to find the exact commit which changed it; in fact it's reproducible at least on 10.2.34 and thus was fixed in one of the next 10 versions.