feat(search): match feature gates by SIMD number - #1251
Conversation
Feature gates registered before the SIMD process carry no SIMD number in their title, so the search bar could not reach them. Match the registry's `simds` field alongside the title, accepting `148`, `0148`, `simd148`, `simd 148` and `SIMD-0148`. A SIMD number matches exactly, not as a prefix. It is often a valid epoch or block number too, so the provider now ranks below the block and epoch providers in the local tier. Parsing lives in `lib/parse-simd-number.ts` beside `parse-natural-number`, covered there without the registry.
|
@askov is attempting to deploy a commit to the Solana Foundation Team on Vercel. A member of the Team first needs to authorize it. |
Greptile SummaryThis PR extends feature-gate search to match exact SIMD numbers while preserving title matching and ranking numeric block and epoch results first.
Confidence Score: 5/5The PR appears safe to merge with no concrete correctness, security, or build failures identified. The parser accepts the documented spellings while rejecting malformed entries, matching remains exact against the current registry shape, and provider ordering does not hide or suppress feature-gate results. Important Files Changed
Reviews (1): Last reviewed commit: "feat(search): match feature gates by SIM..." | Re-trigger Greptile |
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
Description
Feature gates registered before the SIMD process carry no SIMD number in their title —
MoveStake and MoveLamportsis SIMD 148 — so the search bar could not reach them at all. This matches the registry'ssimdsfield alongside the title.Accepted spellings:
148,0148,simd148,simd 148,SIMD-0148. Registry entries are zero-padded and carry stray upstream whitespace (['0178', ' 0189', ' 0377']), so both sides of the comparison parse to a decimal number.A SIMD number matches exactly, not as a prefix, because it is frequently a valid epoch or block number too — 35 of the numbers now reachable are past Solana epochs. For the same reason the provider's priority drops below the block and epoch providers in the local tier, so typing
219still listsEpoch #219above the feature gate.Query parsing lives in
app/features/search/lib/parse-simd-number.ts, beside the existingparse-natural-number.ts, where it is covered without touching the registry.parseNaturalNumberitself cannot serve here: it rejects zero-padding, which the registry stores.Type of change
Testing
Manual testing on the preview deployment — open the search bar and type the query:
148— a gate reachable only by its number → Feature Gates group withMoveStake and MoveLamports, whose title never mentions 1480148,simd148,simd 148,SIMD-0148— every spelling → each returns that same single row162— one number, two gates → two rows, both titledRemove accounts executable flag checks, on different addresses219— a SIMD number that is also an epoch →Epoch #219listed above the Feature Gates groupsimd17— a prefix, not a number → nothing. SIMD 173 and 174 both exist, but a prefix of a SIMD number must not reach them17— the title path is untouched → still findsSIMD-0178/0189/0377: Enables deployment and execution of SBPFv3 programs, matched on the digits inside its title exactly as before this PR355000000— a block number → block result only, no Feature Gates groupMoveStake— the title path still works → unchanged behaviour from before this PRDestination pages the rows above navigate to:
Related Issues
Closes HOO-1185
Checklist
pnpm test,pnpm lint,pnpm typecheck)build:infoscript to update build informationAdditional Notes
Two things worth a reviewer's eye:
Remove accounts executable flag checks. Querying162therefore returns two rows that only the address sublabel distinguishes. Both rows are legitimate accounts, so this PR leaves them as-is.feature-gates.jsonrather than from fixtures, sincescripts/feature-gates/regenerates that file from upstream. Each derivation throws with a specific message if the registry stops carrying the shape it needs, so a regeneration that invalidates a case fails loudly instead of passing silently.