Kotlin "e: Type mismatch: inferred type ... but ... was expected" in CI
A e: ... Type mismatch diagnostic means the Kotlin compiler found a value whose static type is not assignable to the expected type. In CI this most often appears after a library upgrade changed a signature, or when a nullable value reaches a non-null parameter.
What this error means
The Kotlin compile task fails with "e: File.kt: (n, m): Type mismatch: inferred type is String? but String was expected" (or similar), and the same code compiled on an older dependency set.
> Task :app:compileKotlin FAILED
e: /app/src/main/kotlin/User.kt: (22, 30): Type mismatch: inferred type is String? but String was expectedCommon causes
A dependency upgrade changed a signature
CI resolved a newer library version whose method now returns a nullable or different type, so the call site no longer type-checks.
Nullability crossing a platform boundary
A value from Java (a platform type) or a generic is treated as nullable in the strict CI resolution, and it flows into a non-null parameter.
How to fix it
Handle the actual type at the call site
- Read the "inferred type ... but ... was expected" pair to see what changed.
- Convert or guard the value (
?: default,requireNotNull, an explicit cast) so it matches. - Rebuild to confirm the mismatch is resolved.
val name: String = user.displayName ?: "unknown"Pin the dependency version that CI resolves
If the mismatch came from a transitive bump, pin the library so CI and local builds see the same signature.
dependencies {
implementation("com.example:lib:1.4.2") // pin the signature you compiled against
}How to prevent it
- Pin dependency versions (or a version catalog / BOM) so signatures are stable across machines.
- Treat platform types from Java explicitly rather than assuming non-null.
- Review changelogs for signature changes before bumping libraries.