Skip to content

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

Description

@kylebernhardy

Outcome

Complete native mutation and checkpoint publication contracts without implementing source-log semantics in the wrapper.

Acceptance criteria

  • Provide ordered packed upsert/replace-by-ID and delete operations with fully validated batches and deterministic replay behavior.

  • Keep authoritative version/conflict resolution in Harper; do not add a durable per-record version ledger to the wrapper.

  • Expose opaque bounded commit payload publication/readback in native mode; payload and covered mutation state commit together.

  • Serialize apply/commit/publish operations and make publish resolve only after durable commit plus local reader reload.

  • Specify compatibility with standalone commit/reload and prevent plain commits from attaching stale checkpoint claims to new mutations.

  • Treat ambiguous commit/reload failures as uncertain state requiring reopen; preserve native poison and backend recovery semantics.

  • Report queue, apply, commit/reload, visibility and health metrics with versioned Rust/TypeScript codec parity.

  • Enforce commit-after-payload rejection in the writer actor, including queued publish-then-commit and reopened generations. Recovered payload, not poisoned status counters, determines durable progress.

Design

Native Tantivy storage and Harper derived indexes. Native Tantivy files are the only delivery target for standalone use and Harper. Proposed APIs and integration gates are not claims of completed implementation.

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