What causes "Unknown common information request type %d" in apache/shardingsphere?

Check the item code in the message; if it is a common info item like implementation/version, the proxy simply does not support it yet

apache/shardingsphere · warning · FirebirdProtocolException

Unknown common information request type %d

Error message

Unknown common information request type %d

What it means

Thrown when parsing a Firebird common information request whose item type is not END. The source carries a 'TODO implement other request types handle' comment: only the END marker is implemented, so every other common info item (implementation, version, etc.) hits the default branch and throws. This is an explicit coverage gap rather than a client error.

Source

Thrown at database/protocol/dialect/firebird/src/main/java/org/apache/shardingsphere/database/protocol/firebird/packet/command/query/info/type/common/FirebirdCommonInfoPacketType.java:80

        Preconditions.checkNotNull(result, "Cannot find code '%d' in common info type", code);
        return result;
    }
    
    /**
     * Parse and write Firebird common information packet based on the given type.
     *
     * @param data payload to write data to
     * @param type type of common info packet
     * @throws FirebirdProtocolException if the common info packet type is unknown
     */
    public static void parseCommonInfo(final FirebirdPacketPayload data, final FirebirdCommonInfoPacketType type) {
        // TODO implement other request types handle
        switch (type) {
            case END:
                data.writeInt1(END.getCode());
                break;
            default:
                throw new FirebirdProtocolException("Unknown common information request type %d", type.getCode());
        }
    }
    
    @Override
    public boolean isCommon() {
        return true;
    }
}

View on GitHub (pinned to e952770a21)

Solutions

Check the item code in the message; if it is a common info item like implementation/version, the proxy simply does not support it yet
Avoid code paths that query common info items beyond END (e.g. skip server version probes at connection time)
Contribute the missing case to parseCommonInfo() upstream — the TODO marks it as unimplemented
If the item is genuinely unknown (not a valid isc_info_* constant), inspect the request bytes for corruption

Defensive patterns

Strategy: validation

Validate before calling

// only route END to parseCommonInfo; filter everything else beforehand
if (type == FirebirdCommonInfoPacketType.END) {
    FirebirdCommonInfoPacketType.parseCommonInfo(data, type);
} else {
    // unimplemented common info item — skip or answer with an error item per Firebird protocol
    respondUnimplemented(type);
}

Type guard

static boolean isImplementedCommonInfo(final FirebirdCommonInfoPacketType type) {
    return type == FirebirdCommonInfoPacketType.END;
}

Try / catch

try {
    FirebirdCommonInfoPacketType.parseCommonInfo(data, type);
} catch (FirebirdProtocolException ex) {
    // coverage gap (see TODO in source): log the item code and degrade instead of crashing the proxy thread
    log.warn("common info item {} not implemented", type);
}

Prevention

Remember parseCommonInfo currently implements only END — avoid code paths that request implementation/version strings at the common level
Watch upstream releases; the TODO signals more types will land

When it happens

Trigger: Calling FirebirdCommonInfoPacketType.parseCommonInfo(payload, type) with any type other than END — e.g. a client that requests the Firebird implementation string within an op info transaction block.

Common situations: Drivers or tools (flamerobin, isql-style clients, Jaybird) that bundle common info items such as isc_info_implementation or isc_info_version into a request; behavior differs across Firebird client versions.

Related errors

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