Skip to content

Implement mutation batching, commit publication, reader reload, and status #8

Description

@kylebernhardy

Outcome

Provide the indexing lifecycle needed by standalone callers and Harper derived delivery.

Acceptance criteria

  • Packed add, replace-by-primary-key, delete, and replay-safe version suppression are supported.

  • Batches preserve ordering and report per-batch completion without per-record JavaScript callbacks.

  • Commit preparation, payload assignment, publication, rollback, merge-only publication, and reader reload follow Tantivy semantics.

  • The commit payload round-trips versioned opaque checkpoint bytes exactly.

  • Status reports writer health, searchable generation, queue depth, commit/reload state, and last failure.

  • Standalone mode does not invent Harper transaction-log semantics.

  • When storage-wait and blocked-thread counters enter status, update the versioned packed codec and corresponding TypeScript decoder/parity tests together. Report blocked time as a nested part of execution rather than adding it again to execution totals.

Storage integration boundary

Use Tantivy storage through Harper. Harper persists Tantivy state through supported existing storage APIs and its shared derived runtime. No public standalone Rocks factory, native rocksdb-js lease or base-library extension is required. Keep engine behavior shared; prove bounded storage transport and exact durable progress in the real Harper integration. Experimental third-arm benchmarks are optional.

Comment generated by kAIle (GPT-6)

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

area:apiPublic Node.js and native APIarea:nativeRust, Tantivy, and Node-API implementation

Type

Fields

Priority

P3

Projects

No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions