elastic/elasticsearch · error · IOException

database_type too long [size indicator == {}]

Error message

database_type too long [size indicator == {}]

What it means

Thrown by MMDBUtil.getDatabaseType when the database_type field's size indicator is >= 30, meaning the type string would be >= 285 characters. Real Maxmind/Ipinfo type strings are short (e.g. 'GeoIP2-City', 'ipinfo country'); an oversized indicator signals a corrupt metadata section. IOException surfaces during lookup wiring.

Source

Thrown at modules/ip-location/src/main/java/org/elasticsearch/ingest/geoip/MMDBUtil.java:93

            if (metadataOffset == -1) {
                throw new IOException("database type marker not found");
            }

            // read the database type
            final int offsetByte = fromBytes(tail[metadataOffset]);
            final int type = offsetByte >>> 5;
            if (type != 2) { // 2 is the type indicator in the mmdb format for a UTF-8 string
                throw new IOException("type must be UTF-8 string");
            }
            int size = offsetByte & 0x1f;
            if (size == 29) {
                // then we need to read in yet another byte and add it onto this size
                // this can actually occur in practice, a 29+ character type description isn't that hard to imagine
                size = 29 + fromBytes(tail[metadataOffset + 1]);
                metadataOffset += 1;
            } else if (size >= 30) {
                // we'd need to read two or three more bytes to get the size, but this means the type length is >=285
                throw new IOException("database_type too long [size indicator == " + size + "]");
            }

            return new String(tail, metadataOffset + 1, size, StandardCharsets.UTF_8);
        }
    }

    private static int fromBytes(byte b1) {
        return b1 & 0xFF;
    }

    public static boolean isGzip(Path path) throws IOException {
        try (InputStream is = Files.newInputStream(path); InputStream gzis = new GZIPInputStream(is)) {
            gzis.read(); // nooping, the point is just whether it's a gzip or not
            return true;
        } catch (ZipException e) {
            return false;
        }
    }

View on GitHub (pinned to db6a809a66)

Solutions

1. Validate the file with the official mmdb tool.
2. Re-download the database to eliminate corruption.
3. Confirm the file is genuinely mmdb and not another format that matched the marker by chance.
4. If a legitimate type is extremely long (unlikely), the size parsing would need extension (code change).

try {
    String type = MMDBUtil.getDatabaseType(path);
} catch (IOException e) {
    if (e.getMessage().startsWith("database_type too long")) {
        // size byte indicates a corrupt metadata section; re-download and revalidate
    } else throw e;
}

When it happens

Trigger: getDatabaseType: size = offsetByte & 0x1f; size >= 30 -> throw. The mmdb extended-size encoding would require two or three more bytes, which the implementation declines to parse.

Common situations: Corrupt mmdb metadata giving a garbage size byte; a non-mmdb file whose post-marker byte happens to have low 5 bits >= 30; bit-level corruption.

Related errors

• database type marker not found
• type must be UTF-8 string
• failed to skip [{}] bytes while reading [{}]
• checksum mismatch, expected [{}], actual [{}]
• md5 checksum mismatch, expected [{}], actual [{}]

AI-assisted analysis of elastic/elasticsearch@db6a809a66 (2026-08-12). Data as JSON: /api/errors/1b3f5d0887d4696c. Report an issue: GitHub.