License scanning unavailable: deps.dev returns gRPC Unavailable

[dustyghost]

Summary

OSV-Scanner licence scanning is repeatedly failing after successful package
extraction because the upstream deps.dev request returns gRPC Unavailable.

This appears to be a recurrence of #2737, which was previously attributed to
intermittent deps.dev API unavailability.

Environment

• OSV-Scanner: 2.4.0
• OSV-Scalibr: 0.4.5
• Commit: b56b5191101d5f27d4787d5583d8d01e9518a7af
• Platform: Linux amd64
• Date observed: 25 July 2026
• Inputs: one Go module and one npm lockfile

Command shape

osv-scanner scan source \
  --lockfile <path>/go.mod \
  --lockfile <path>/package-lock.json \
  --licenses \
  --all-packages \
  --format json \
  --output-file <path>/license-inventory.json

Actual behaviour

Package extraction succeeds:

Scanned <path>/go.mod file and found 8 packages
Scanned <path>/package-lock.json file and found 274 packages
End status: 0 dirs visited, 2 inodes visited, 2 Extract calls
rpc error: code = Unavailable desc = service unavailable

The command returns status 127 and does not produce a valid JSON inventory.
Five attempts with exponential delays of 15, 30, 60 and 120 seconds all failed
with the same response. The failure has also been observed on repeated runs
during the day.

Expected behaviour

Licence inventory succeeds, or the scanner provides a supported
resilient/offline path for licence metadata when deps.dev is temporarily
unavailable.

Questions

1. Is deps.dev currently experiencing a known incident or regional degradation?
2. Is there a public status channel for OSV-Scanner's deps.dev dependencies?
3. Is there a supported way to cache or use previously resolved licence
   metadata when dependency inputs are unchanged?
4. Would the project consider distinguishing this upstream infrastructure
   failure more explicitly in the exit status and diagnostics?

No repository source or private package names are included in this report.

[sudo-bmitch]

Looks like the service has been restored.

[another-rex]

We'll keep monitoring this, but currently it's not reproducable as service has been restored.

You're right that osv-scanner should better distinguish upstream failures and still produce a report.

[ting-hong-shieh]

On current main (after #2935), deps.dev failures surface as a failed license/depsdev plugin status. pkg/osvscanner/scan.go reports this as “Error during extraction”, which leads to the generic exit code 127. OSV-Scanner already reserves ErrAPIFailed and exit code 129 for API/network failures, but that path is unused here.

I propose a narrow fix:

1. Treat a failed license/depsdev status as an ErrAPIFailed-wrapped deps.dev failure.
2. Preserve the extracted inventory and write the report before returning the error, so --output-file contains valid partial output.
3. Write a specific stderr diagnostic stating that license enrichment failed and the report is incomplete.
4. Preserve license data already found during extraction, but leave missing license data unset when the deps.dev request fails. Setting it to UNKNOWN would conflate an unavailable upstream service with a package whose license could not be identified.

This patch would not add caching or offline license lookup, nor would it change the JSON schema. Those require separate design decisions.

The regression test would inject a fake gRPC connection whose deps.dev GetVersion returns codes.Unavailable. It would assert exit code 129, valid JSON containing the extracted packages when --all-packages is set, and an incomplete-license diagnostic on stderr. It would not depend on a live deps.dev outage.

One behavior still needs confirmation: if the partial report also contains vulnerabilities, I propose that exit code 129 take precedence over exit code 1 because the requested license scan is incomplete. If vulnerability exit code 1 should remain dominant, I can encode that instead.

If this scope looks right, could you assign the issue to me before I start implementation?