There are Oracle bug reports that indicate that LogMiner may mistakenly emit transactions that are rolled back in the commit data only mode.

One example of such reports:
https://support.oracle.com/knowledge/Oracle%20Database%20Products/3035579_1.html

This was brought up on Zulip here:
https://debezium.zulipchat.com/#narrow/channel/348250-community-oracle/topic/Rollback.20event.20with.20SCN.20found.20but.20should.20not.20in.20this.20mode/near/517143527

From what we've been able to identify thus far, the table this happens for has DDL:

create table ASYNC_TRIGGER1_QTAB
(
NAME VARCHAR2(128),
MID RAW(16),
CID VARCHAR2(128),
PRI NUMBER,
STATE NUMBER,
DELAY TIMESTAMP(6),
EXP NUMBER,
T_INFO TIMESTAMP(6),
L_NO NUMBER,
 C_NO NUMBER,
CCN NUMBER,
DCN NUMBER,
E_TIME TIMESTAMP(6),
E_UID VARCHAR2(128),
E_TID VARCHAR2(128),
D_TIME TIMESTAMP(6),
D_UID VARCHAR2(128),
D_TID VARCHAR2(128),
RETRY_COUNT NUMBER,
EXCEPTION_SCHEMA VARCHAR2(128),
EXCEPTION_Q VARCHAR2(128),
S_NO NUMBER,
R_KEY NUMBER,
D_MSGID RAW(16),
S_NAME VARCHAR2(128),
S_ADDR VARCHAR2(1024),
S_PROT NUMBER,
U_DATA OLARGEOBJECT,
U_PROP SYS.ANYDATA
)

The OLARGEOBJECT data type is a synonym for CLOB.

The event data shows an INSERT into the table, followed by an UPDATE where the U_PROP column is set to NULL. The U_PROP column is first initialized as EMPTY_CLOB() and then the LOB operation UPDATEs the column with the NULL.

Locally, the transaction is rolled back and isn't captured on Oracle 19.3; however the user is on Oracle 19.15.0.0.0, so perhaps there is a patch that broke the behavior or there is something with how the user's application is creating the data that isn't obvious.

I've asked the user to supply more details.