[Bug]: MigrationMetrics has unbounded error type cardinality (memory leak risk)

[Splatcrafter]

AI REVIEWED

Module: spring-boot-starter
File: spring/metrics/MigrationMetrics.java (~line 324)
Severity: High

Summary

error.getClass().getSimpleName() is used as a Micrometer metric tag for failure counters. This creates unbounded cardinality — a well-known Micrometer anti-pattern that leads to memory leaks when many distinct exception types are thrown.

Additional issues:

• Anonymous inner classes produce ugly names like Exception$1
• Dynamic proxy exceptions produce unpredictable names
• Each unique error type creates a new cached Counter in the ConcurrentHashMap

Expected Behavior

Error types should be classified into a bounded set of categories.

Actual Behavior

getOrCreateFailureCounter(domain, error.getClass().getSimpleName()).increment();

Suggested Fix

Classify errors into known categories:

private String classifyError(Throwable error) {
    if (error instanceof FixException) return "fix_error";
    if (error instanceof DecodeException) return "decode_error";
    if (error instanceof EncodeException) return "encode_error";
    return "unknown_error";
}

Or limit total distinct error types with an LRU cache.