computeAffectedVersions narrows coarse window after SortEvents lexicographic fallback

Open Beginner friendly
#5,824 3 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
74/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Quiet
Tech stack
go
Domain
database

Research direction

Start in go/internal/database/datastore/affected_versions.go at computeAffectedVersions and trace its call to osvutil.SortEvents, then inspect how buildVersionMatcher uses coarse_min and coarse_max. Add a unit test for the documented Packagist-style fallback case; done means a SortEvents error leaves both coarse bounds unbounded so the semantic matcher can find the affected version.

Written by the indexing model from the issue text.

Description

Summary

In go/internal/database/datastore/affected_versions.go, computeAffectedVersions calls osvutil.SortEvents and discards the error:

_ = osvutil.SortEvents(eHelper, events)

When any event version fails Parse/Compare, SortEvents re-sorts lexicographically (documented as arbitrary/stable) and returns that error to signal the order is not semantic. The caller still derives coarse_min / coarse_max from positional assumptions that only hold under a semantic sort (first introduced, last event).

Those coarse bounds become hard Datastore inequality filters in buildVersionMatcher, so a row excluded by a wrongly-narrowed window is never returned to the semantic matcher.

Worked example (Packagist)

Events: introduced 1.0, fixed 9.0, introduced 20.0, fixed 30.0, introduced 1.0#bad (Packagist rejects #).

Lexicographic fallback order ends with fixed 9.0, so today's code emits coarse_max = coarse(9.0). Version 25.0 is semantically in-range (20.030.0) but fails the coarse_max >= coarse(25.0) pre-filter.

Expected

On SortEvents error, leave coarse_min/coarse_max at the unbounded defaults (00:000… / 99:999…), matching the Python _get_coarse_min_max ValueError path that resets to MIN/MAX.

Note

This is a correctness / false-negative matching bug in the Go datastore index path (live importer/worker), not a security advisory request. Happy to send a small patch + unit test once this is assigned per CONTRIBUTING.

Dominant language
Go
Stars
2.9k
Forks
371
Avg merge
1d 11h
Merged PRs (30d)
111

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from google/osv.dev

All issues in google/osv.dev

Similar issues

More Go issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.