Align direct Rust search validation with the public packed API

Aperta
  • Qualcosa non va?
#65 1 commento 0 reazioni 1 assegnatario Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

@kylebernhardy ci sta già lavorando.

Dal 30/10/2026.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
38/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
nodejs, rust
Ambito
api, backend, testing-qa

Direzione di ricerca

Start by comparing decode_search, the facade, and Engine::search at the assessed source revision; inventory the checks named in the acceptance criteria and separate transport constraints from engine invariants. Then review the autocomplete window and query and filter validation paths, and the existing boundary and collector tests. Done means documented direct Rust guarantees, centralized applicable guards, paired direct Rust and packed boundary tests, and independent collector-equivalence tests that do not rely on the new guard.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Outcome

Define and enforce one explicit request-validation contract for public Rust Engine calls and the Node/packed API.

Evidence and scope

In the assessed fulltext source, legacy prefix/fuzzy-prefix offset-zero and 100-hit restrictions are checked in decode_search; direct Rust SearchRequest construction reaches Engine::search without that decoder. The traversal implementation shares checked ordinary/traversal window validation, but broader Rust/packed parity remains deferred. This observation is scoped to that base protocol/engine. Harper uses the protected Node API, not direct Rust construction; its separate raw-batch iteration defect is tracked in Support full-text and autocomplete continuation in Table.search and REST. No Node boundary bypass or production incident is claimed.

Acceptance criteria

  • Inventory decoder, facade and engine checks, including autocomplete windows, candidates, query/filter complexity, strings and numeric values. Distinguish transport constraints from engine invariants.
  • Decide/document supported direct Rust construction guarantees, then centralize applicable semantic guards before allocation or query work.
  • Add paired direct-Rust and packed boundary tests. Preserve explicit errors and the distinction between legacy search and traversal.
  • Keep independent collector-equivalence tests independent of the new public request guard; use a lower-level query/collector oracle where needed.

Parent: Epic: Extend fulltext search capabilities beyond the initial wrapper API. Follow-up to Add bounded deep-result traversal and qualify autocomplete limits; not an additional Node pagination feature.

Priority: P3; API hardening, with the public packed boundary already protected and no observed incident. Effort: Medium; shared validation and boundary/oracle tests. No committed milestone, customer-specific context or security incident.

Validated-request carrier follow-up

Semantic validation is deliberately applied at both public decoding and Engine boundaries: decoding returns a publicly mutable SearchRequest, which can be changed before Engine execution. The shared guard keeps direct Rust calls fail-closed. The redundant third trace-field identity set was removed; three paired finite default-trace controls passed the established regression criterion.

  • If profiling demonstrates material cost from repeated admission, consider an internal opaque validated-request carrier that cannot be constructed or mutated without checking. Preserve all direct/public Engine guarantees and raw decoder validation; do not add an unchecked execution route merely to skip a bounded walk.

This is a performance optimization follow-up, not an unclosed Node validation bypass. Keep P3/Medium with no release milestone: no measured customer degradation or committed optimization exists.

Review-Deferral: cffd6ea90520e832 severity=nit category=performance

Query-controls review follow-up

Packed searches repeat semantic admission at the public engine boundary. This remains the accepted safety tradeoff for mutable decoded requests; evaluate a provenance-safe optimization without adding an unchecked public entry point. See Expose fuzzy matching controls and align Rust request validation.

Review-Deferral: fc1168ff35d58a28 severity=nit category=performance

Search preparation error consistency

  • Decide whether arbitrary search-preparation throws should normalize consistently with invocation and trace encoding, preserving explicit codes and causes. Add paired throwing-getter and asynchronous-preparation tests.

This pre-existing consistency nit preserves caller error identity in the observability work; it is not a demonstrated validation bypass. Trigger and scope. Priority P3/Medium and release scope remain unchanged.

Review-Deferral: 90ddd36244cc9d01 severity=nit category=maintainability

Comment generated by kAIle (GPT-6)

Lingua principale
Rust
Stelle
3
Fork
0
Merge medio
15h 12m
PR unite (30g)
11

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di HarperFast/fulltext

Tutte le issue di HarperFast/fulltext

Issue simili

Altre issue su Rust

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.