Align direct Rust search validation with the public packed API

オープン
  • 何か問題がありますか？
#65 コメント 1 件 リアクション 0 件 担当者 1 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

@kylebernhardy がすでに取り組んでいます。

2026年10月30日 から。

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
38/100
issue の種類
機能追加
明瞭さ
おおむね明確
活発さ
活発
技術スタック
nodejs, rust
領域
api, backend, testing-qa

調査の方向性

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.

索引モデルが issue の本文から書いたものです。

説明

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)

主要言語
Rust
スター
3
フォーク
0
平均マージ
15時間 12分
マージ済み PR（30日）
11

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

HarperFast/fulltext のほかの issue

HarperFast/fulltext の issue をすべて見る

似ている issue

Rust の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。