Crash in the PyPI importer?

[woodruffw]

Hello OSV folks!

Describe the bug

I was looking at pypa/advisory-database's OSV ingestion, and I noticed that the OSV ingestor (which is implemented in this repo but runs in the CI there) appears to be failing.

Example failing job:

https://github.com/pypa/advisory-database/actions/runs/23661246588/job/68931794611

Excerpted failure:

panic: runtime error: index out of range [0] with length 0

goroutine 1 [running]:
main.loadExisting.func1({0x1786a097e090, 0x23}, {0xfec950?, 0x1786cd6bf860?}, {0x0?, 0x0?})
	/home/runner/go/pkg/mod/github.com/google/osv/vulnfeeds@v0.0.0-20260327050509-02cae864f15f/cmd/pypi/main.go:66 +0x5c5
path/filepath.walk({0x1786a097e090, 0x23}, {0xfec950, 0x1786cd6bf860}, 0x17870c20d590)
	/home/runner/go/pkg/mod/golang.org/toolchain@v0.0.1-go1.26.1.linux-amd64/src/path/filepath/path.go:346 +0x105
path/filepath.walk({0x178704ad45b0, 0xd}, {0xfec950, 0x1786cd6bf790}, 0x17869e14b590)
	/home/runner/go/pkg/mod/golang.org/toolchain@v0.0.1-go1.26.1.linux-amd64/src/path/filepath/path.go:370 +0x245
path/filepath.walk({0x7fff33e5fc85, 0x5}, {0xfec950, 0x1786cd6bf5f0}, 0x17869e14b590)
	/home/runner/go/pkg/mod/golang.org/toolchain@v0.0.1-go1.26.1.linux-amd64/src/path/filepath/path.go:370 +0x245
path/filepath.Walk({0x7fff33e5fc85, 0x5}, 0x17870c20d590)
	/home/runner/go/pkg/mod/golang.org/toolchain@v0.0.1-go1.26.1.linux-amd64/src/path/filepath/path.go:428 +0x66
main.loadExisting({0x7fff33e5fc85, 0x5})
	/home/runner/go/pkg/mod/github.com/google/osv/vulnfeeds@v0.0.0-20260327050509-02cae864f15f/cmd/pypi/main.go:43 +0x4f
main.main()
	/home/runner/go/pkg/mod/github.com/google/osv/vulnfeeds@v0.0.0-20260327050509-02cae864f15f/cmd/pypi/main.go:132 +0x505
Error: Process completed with exit code 2.

To Reproduce

I don't have a local reproducer, sorry. You can see that it's been consistently failing in CI for a while here:

https://github.com/pypa/advisory-database/actions/workflows/auto_import.yaml

Expected behaviour

I expected github.com/google/osv/vulnfeeds/cmd/pypi@master to not crash.

Screenshots

N/A

Additional context

I suspect this ingestor failure means that there's a large backlog of OSV records that haven't been assigned PYSEC IDs.

CC @miketheman @sethmlarson

[G-Rath]

I'm guessing that there is an advisory without any affected versions:

osv.dev/vulnfeeds/cmd/pypi/main.go

Lines 66 to 69 in 02cae86

	ids[vuln.GetId()+"/"+vuln.GetAffected()[0].GetPackage().GetName()] = true
	for _, alias := range vuln.GetAliases() {
	ids[alias+"/"+vuln.GetAffected()[0].GetPackage().GetName()] = true
	}

[jess-lowe]

I'll look into this and see if I can resolve it on our end.

[jess-lowe]

I've been doing a lot of changes and refactors to the CVE Conversion process of late so it may be that one of those changes introduced a regression in the PyPi workflow. Temporary remediation could involve moving the pin to a commit in the past where we know it was stable, while I investigate the regression.