Skip to content
Latchkey

Gradle "Dependency lock state ... is out of date" in CI

With dependency locking enabled, Gradle compared what it resolved against the committed lock state and they differ. It refuses to silently use unlocked versions and lists which modules were added, removed, or changed.

What this error means

The build fails with "Dependency lock state for configuration ':app:runtimeClasspath' is out of date:" followed by lines naming modules that are in the lock state but not resolved, or resolved but not locked.

Gradle
> Dependency lock state for configuration ':app:runtimeClasspath' is out of date:
    Resolved 'com.example:widgets:1.5.0' which is not part of the dependency lock state
    Did not resolve 'com.example:widgets:1.4.0' which is part of the dependency lock state

Common causes

A dependency changed without updating the lockfile

You bumped or removed a dependency but did not regenerate gradle.lockfile, so the resolved graph no longer matches the locked one.

A transitive version moved under the pins

A direct upgrade pulled a different transitive version than the lock records, so locking flags the drift.

How to fix it

Regenerate the lock state

  1. Run the build with --write-locks to rewrite the lockfiles from the current resolution.
  2. Review the lockfile diff to confirm the changes are intended.
  3. Commit the updated lockfiles alongside the dependency change.
Terminal
./gradlew dependencies --write-locks

Keep locking strict and update deliberately

Leave lock validation on in CI so drift fails the build, and regenerate locks only when you intend to change versions.

build.gradle.kts
dependencyLocking {
  lockAllConfigurations()
}

How to prevent it

  • Regenerate lockfiles in the same commit that changes a dependency.
  • Review lockfile diffs so unexpected transitive moves are caught.
  • Keep lock validation enabled in CI rather than disabling it to pass.

Related guides

Tired of flaky CI? Latchkey auto-heals failed jobs and retries them for you. Start free →