apache/shardingsphere · error · IngestException

Unknown rowEventType: %s

Error message

Unknown rowEventType: %s

What it means

TestDecodingPlugin (PostgreSQL incremental ingest using the test_decoding output format) reads the table event's operation token and converts it with PipelineSQLOperationType.valueOf; an unrecognized token throws IngestException('Unknown rowEventType: <token>'). The expected tokens are the PostgreSQL test_decoding op codes (INSERT/UPDATE/DELETE); anything else — message-protocol changes, BEGIN/COMMIT tags leaking into row parsing, or plugin-format drift — fails fast.

Source

Thrown at kernel/data-pipeline/dialect/postgresql/src/main/java/org/apache/shardingsphere/data/pipeline/postgresql/ingest/incremental/wal/decode/TestDecodingPlugin.java:77

        } else {
            result = "table".equals(type) ? readTableEvent(data) : new PlaceholderEvent();
        }
        result.setLogSequenceNumber(logSequenceNumber);
        return result;
    }
    
    private String readEventType(final ByteBuffer data) {
        return readNextSegment(data);
    }
    
    private AbstractRowEvent readTableEvent(final ByteBuffer data) {
        String tableName = readTableName(data);
        String rowEventType = readRowEventType(data);
        PipelineSQLOperationType type;
        try {
            type = PipelineSQLOperationType.valueOf(rowEventType);
        } catch (final IllegalArgumentException ex) {
            throw new IngestException("Unknown rowEventType: " + rowEventType);
        }
        AbstractRowEvent result;
        switch (type) {
            case INSERT:
                result = readWriteRowEvent(data);
                break;
            case UPDATE:
                result = readUpdateRowEvent(data);
                break;
            case DELETE:
                result = readDeleteRowEvent(data);
                break;
            default:
                throw new IngestException("Unknown rowEventType: " + rowEventType);
        }
        String[] tableMetaData = tableName.split("\\.");
        result.setSchemaName(tableMetaData[0]);
        result.setTableName(tableMetaData[1].substring(0, tableMetaData[1].length() - 1));

View on GitHub (pinned to e952770a21)

Solutions

  1. Verify the replication slot's plugin matches what the pipeline expects: recreate the slot with test_decoding if the job uses TestDecodingPlugin.
  2. Inspect the logged rowEventType token; if it is BEGIN/COMMIT or JSON, the stream format does not match this decoder — fix plugin/config alignment.
  3. Recreate the replication slot and restart incremental ingestion from a consistent position after desynchronization.
  4. Prefer a supported, version-matched decoding setup per the ShardingSphere pipeline documentation for your PostgreSQL version.

Example fix

-- before: slot uses wal2json but pipeline expects test_decoding
SELECT * FROM pg_create_logical_replication_slot('slot1', 'wal2json');

-- after
SELECT * FROM pg_create_logical_replication_slot('slot1', 'test_decoding');
Defensive patterns

Strategy: validation

Validate before calling

-- preflight: slot plugin must match the decoder the pipeline uses
SELECT slot_name, plugin FROM pg_replication_slots WHERE slot_name = 'slot1';
-- expected: plugin = 'test_decoding' when TestDecodingPlugin is configured

Try / catch

try {
    WALEvent event = plugin.decode(buffer);
} catch (final IngestException ex) {
    if (ex.getMessage().startsWith("Unknown rowEventType")) {
        // slot/decoder mismatch or desync: recreate slot with correct plugin, restart from snapshot
    }
}

Prevention

When it happens

Trigger: Running PostgreSQL logical replication with test_decoding where a row message carries an operation token that valueOf cannot resolve: malformed stream desynchronization (wrong segment-reading order), a different decoding plugin actually configured (wal2json output parsed as test_decoding), or an unexpected message type.

Common situations: Replication slot created with wal2json/pgoutput but the pipeline configured for test_decoding (or vice versa); stream desync after a dropped connection, so readNextSegment returns garbage tokens; PostgreSQL version differences in test_decoding output; messages for non-row operations parsed as row events.

Related errors


AI-assisted analysis of apache/shardingsphere@e952770a21 (2026-08-14). Data as JSON: /api/errors/b7465c503a2b7b52. Report an issue: GitHub.