SQLite typed lookup API fails with no such column: 'rowid'

[yabooo666]

CoreProtect-CE 24.0 throws a SQLite exception when using the new typed lookup APIs with a player filter.

Affected methods include:

CoreProtectAPI.chatLookup(...)
CoreProtectAPI.commandLookup(...)

The exception happens while CoreProtect is resolving the player ID.

Error

java.sql.SQLException: no such column: 'rowid'
    at org.sqlite.jdbc3.JDBC3ResultSet.findColumn(JDBC3ResultSet.java:51)
    at org.sqlite.jdbc3.JDBC3ResultSet.getInt(JDBC3ResultSet.java:336)
    at net.coreprotect.api.MessageAPI.getUserId(MessageAPI.java:99)
    at net.coreprotect.api.LookupFilter.fromOptions(LookupFilter.java:32)
    at net.coreprotect.api.MessageAPI.performLookup(MessageAPI.java:53)
    at net.coreprotect.api.MessageAPI.performChatLookup(MessageAPI.java:30)
    at net.coreprotect.CoreProtectAPI.chatLookup(CoreProtectAPI.java:291)

The same issue also occurs with commandLookup(...).

Expected behavior

The typed API should return matching chat or command results for the specified player.

Actual behavior

CoreProtect logs the SQL exception and returns an empty result list.

API consumers therefore only see “no results,” even when matching data exists.

Possible cause

The problem appears related to SQLite rowid alias handling.

For example, if a query uses:

SELECT rowid AS id, ...

but the result is later read using:

resultSet.getInt("rowid")

SQLite JDBC cannot find a result column named rowid, because it was aliased as id.

The result should instead be read using:

resultSet.getInt("id")

or the query should return rowid without renaming it.

Environment

• CoreProtect-CE: 24.0
• Database: SQLite
• Server software: Folia
• Minecraft: 1.21.11
• Java: 21

Steps to reproduce

1. Enable the CoreProtect API.
2. Use SQLite.
3. Call a typed lookup method with a player filter:

LookupOptions options = LookupOptions.builder()
        .user("PlayerName")
        .time(86400)
        .limit(0, 100)
        .build();

coreProtectApi.chatLookup(options);

4. Check the server console.

Additional information

The older generic performLookup(...) API does not produce this exact exception.

The problem started when switching an integration from the generic lookup API to the new typed APIs.