Align direct Rust search validation with the public packed API

Abierto
  • ¿Algo no está bien?
#65 1 comentario 0 reacciones 1 asignado Ver en GitHub

Los mantenedores suelen responder en 1 día

@kylebernhardy ya está trabajando en esto.

Desde el 30/10/2026.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
38/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
nodejs, rust
Área
api, backend, testing-qa

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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)

Lenguaje dominante
Rust
Estrellas
3
Forks
0
Merge medio
15 h 12 min
PR fusionados (30 d)
11

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de HarperFast/fulltext

Todos los issues de HarperFast/fulltext

Issues similares

Más issues de Rust

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.