Fix stale didYouMean props#81
Open
Eric Hibbs (flowstate) wants to merge 5 commits into
Open
Conversation
Resolves CUS2-5. The didYouMean class declared four props
(alternatePackage, downloads, downloadsRatio, editDistance) but the
current OpenAPI schema (socket-sdk-js/openapi.json:9298) only emits
{ alternatePackage, detectedAt }. The three stale keys were dead at
runtime and detectedAt was missing a human-readable label entirely.
Updated to match the schema.
|
🚀 Preview package published! Install with: pip install --index-url https://test.pypi.org/simple/ --extra-index-url https://pypi.org/simple socketdev==3.1.1.dev1 |
…stale-didyoumean-props # Conflicts: # socketdev/version.py
Run via .hooks/sync_version.py after merging origin/main (now at 3.1.0 from lelia's purl PR). Keeps pyproject.toml and socketdev/version.py in lockstep, as flagged in code review.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The
didYouMeanalert class in socketdev/core/issues.py declared four props keys but the Socket API only emits two of them. Three keys (downloads,downloadsRatio,editDistance)were dead at runtime — consumers rendering prop labels (PR comments, security comments, dependency overview tables) showed column headers for fields that never populated.
Meanwhile
detectedAt, which the API does emit, had no human-readable label.Root Cause
The didYouMean props dict drifted from the schema — openapi.json around line 9298 declares props:
{ alternatePackage, detectedAt }, and the python class never caught up.Fix
Replaced the stale four-key dict with { alternatePackage, detectedAt } to match the OpenAPI schema. Added tests/unit/test_issues_did_you_mean_props.py with two contract tests — one pins the key set against the schema, one guards that every key has a non-empty label — so future drift is caught locally.
Purely a contract correction; no behavioral change beyond the keys exposed by
AllIssues().didYouMean.props.Sibling work in CUS2-4 added a
gptDidYouMeanclass with the same correct shape; this PR brings the existingdidYouMeaninto alignment.Public Changelog