Skip to content

stack-encrypt: replace Supports::check, verifier and admit with one prepare, called once per query #1318

Open

Description

@tobyhede

Parent

#1279

What to build

op::Supports is how an index says which operators it answers and what a query on it refuses. Today it has three overlapping methods: check (refuse), verifier (keep what a probabilistic query needs to check rows later, such as a match query's tokens), and admit (check then verifier). The match impl's verifier hides a failure with unwrap_or_default, and is only correct because admit ran first. The typed query chain calls check before it resolves the keyset and admit after, so a match query cuts its text into tokens twice.

Replace the three with one method: prepare(&self, input) -> Result<Verifier, Error>. Then a verifier can only exist for an input the index accepted. The query chain calls it once, before the keyset is resolved, and keeps the verifier until it derives the term.

Supports is new in stack-encrypt 0.3.0, which is not published yet (crates.io has 0.2.0), so this changes nothing a released user depends on.

Acceptance criteria

  • Supports has prepare and no check, verifier or admit; every built-in impl (equality, match, ORE, OPE, for each operator) implements it.
  • The typed query chain calls prepare exactly once per query, before the keyset is resolved, and no longer tokenizes a match query twice.
  • No unwrap_or_default remains on a verifier path.
  • Every refusal keeps its error variant and stable diagnostic code; the table test from the first ticket passes unchanged.
  • The trybuild UI test that implements Supports outside the crate is updated, and any snapshots whose text changes are re-recorded.
  • The unreleased op::Supports entries in stack-encrypt's CHANGELOG are edited in place to describe prepare; no breaking-change line is added.
  • cargo-mutants --in-diff leaves no surviving mutant in the changed code.

Blocked by

Activity

  1. coderdan commented on Oct 21, 2026

    @coderdan
    Contributor

    Verifier is only useful for probabilistic queries. Would that mean that most verifiers would be a no-op?

    The proposal returns a concrete Verifier so, it's impossible to extend with third-party crates. Internally it would have to be done via an enum within stack-encrypt itself to handle the different kinds of verifiers.

    Would prefer something like:

    trait Query { // name?
        type Verifier: Verifier;
        fn prepare(&self, input) -> Result<Self::Verifier, Error>;
    }
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    SDKenhancementNew feature or requestready-for-agentFully specified and ready for an AFK agent

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions