[Jeppe Fredsgaard Blaabjerg (jfblaa)]

LLM Description written by Claude Code:claude-opus-5-5

Reachability reads a sidecar component with no targets as not installed, and targets: [] as resolved with no artifact. A component whose files were gone from disk got the surviving subset, or an empty list, so it looked resolved.

• New unfetched record lets a producer mark an artifact it could not fetch. Nothing emits it yet; the Maven, Gradle and sbt PRs above do.
• A component with any unfetched or missing file gets no targets.

Testing: new assembler/sidecar unit test.

🤖 Generated with Claude Code

---

Note

Medium Risk
Changes how reachability classifies JVM dependencies when jars are missing or unfetched; incorrect marking could skip or mis-analyze dependencies, but scope is limited to facts/sidecar assembly with new tests.

Overview
JVM Socket facts assembly now distinguishes unresolved artifacts from resolved-but-empty ones in reachability sidecars. A new unfetched line-protocol record (for Maven/Gradle/sbt producers) marks coordinates whose jars could not be fetched; assembly also treats any listed classpath file that is missing on disk as incomplete.

External components with a partial or missing artifact no longer emit targets (or an empty subset). targets: [] still means resolved with no jar (e.g. a BOM). targets omitted means not installed—so reachability will not treat broken or unfetched deps as fully resolved.

Types and attachPaths in the sidecar path were updated so ResolvedArtifactPaths.targets is optional; a unit test covers unfetched, missing files, and multi-classifier cases.

^{Reviewed by Cursor Bugbot for commit 89d3769. Configure here.}

[Martin Torp (mtorp)]

[agent] Approving, with one inline note.

One note for the whole stack. The Maven, Gradle and sbt compat suites are the only tests that exercise most of the new producer code, and none of them run in CI (only the TS unit tests, lint, types and e2e do). A lot of this code leans on build-tool internals: the resolver's collector and trace layout, copies of JavaScopeDeriver and ClassicDependencyManager, coursier's cache layout, Ivy's report files and Gradle's error text. A slim matrix in CI or a nightly job, one old and one current version per tool, would catch it when one of those shifts.

[Jeppe Fredsgaard Blaabjerg (jfblaa)]

[agent] On running the compat suites in CI: agreed, they're the only coverage for the build-tool internals. They can't run on GitHub Actions today because SocketDev's action allowlist forbids actions/setup-java and sbt/setup-sbt (see the header of src/commands/manifest/scripts/test/run-compat.sh). For this round, every fix was run against the full Maven, Gradle and sbt matrices locally, and each new fixture was checked to fail without its fix. A nightly job would need a runner with JDKs or an allowlist change.