We applied lockfiles in our projects and almost immediately we started seeing issues with dependencies which are not locked even though they should be. We run the resolveAndLock --write-locks task and it creates the lockfiles but after that when we run ./gradlew clean build it fails with:

> Could not resolve all files for configuration ':project:runtimeClasspath'.
   > Resolved 'com.google.code.findbugs:annotations:2.0.0' which is not part of the dependency lock state

Output from ./gradlew dependencyInsight --configuration runtimeClasspath --dependency com.google.code.findbugs:annotations

com.google.code.findbugs:annotations:2.0.0 FAILED
   Selection reasons:
      - By constraint : Dependency locking
   Failures:
      - Dependency lock state out of date:
          - Resolved 'com.google.code.findbugs:annotations:2.0.0' which is not part of the dependency lock state

com.google.code.findbugs:annotations:2.0.0 FAILED
+--- runtimeClasspath
(can't share the following due to legal limitations but I can tell it contains BOM that sets the version as a constraint and a dependency which brings it transitively without a specified version)

Lockfiles code snippet:

dependencyLocking {
    lockAllConfigurations()
}


tasks.register('resolveAndLockAll') {
    doFirst {
        assert gradle.startParameter.writeDependencyLocks
    }
    doLast {
        configurations.findAll {
            // Add any custom filtering on the configurations to be resolved
            it.canBeResolved
        }.each { it.resolve() }
    }
}

dependencyLocking {
    lockMode = LockMode.STRICT
}

Is there anything else we can check on the environment to get more details why the dependency resolution failed or why didn't the resolveAndLock resolve this dependency?

Expected Behavior

Building the project after executing resolveAndLock should pass successfully.

Current Behavior

Building the project after executing resolveAndWriteLocks fails on dependency lock state

Context

This issue brings a lot of inconvenience into working with lockfiles. The current workarounds we found for the issue are either adding the problematic dependency to the specific project where it fails, or excluding the dependency from all configurations in that project.

Steps to Reproduce

Due to legal restrictions we can't share an example project. We did try to reproduce it on a toy project but it didn't reproduce.

Your Environment

Gradle versions tested (where the bug still reproduce) - 6.7.1, 6.9.1, 7.3.1
Lockfiles applied with STRICT mode