Outcome
Implement the Harper integration factory and generation lifecycle after the real storage proof.
Acceptance criteria
-
Add the planned /harper export only with a tested Harper-owned integration context; no standalone /rocks factory, raw native lease or database path.
-
Use the same engine, query, commit/reload and error paths as native mode.
-
Validate qualified Harper integration and persisted-format compatibility before index activation.
-
Bind handles to the actual store/index/generation; close, drop or recreation invalidates stale contexts.
-
Drain or fail outstanding native/storage requests safely during worker exit and store shutdown.
-
Seal/recover abandoned working objects, reclaim orphans and retire generations with bounded crash-safe operations.
-
Pass real Harper backup/restore, generation swap, storage pressure and close tests; use shared Harper replay/rebuild semantics.
-
Graceful close keeps storage servicing available until writers finish or roll back, merge tasks exit, searches release slices, and transport requests settle; never synchronously join native work from the JS environment needed to service its storage.
-
On worker loss or Harper's shutdown deadline expiry, a surviving lifecycle path fails pending requests and wakes native waiters. Cancellation does not prove an executing write stopped or rolled back. Fence late completions and retain request state within the transport budget until the last possible access is gone; a timeout never authorizes freeing live state.
-
Use Harper's shared close/drop lifecycle and supported storage APIs; prove safe store-view release without new private rocksdb-js close hooks. Test active reads, merge, publication, late responses, and repeated failed teardown without unbounded retained state.
-
All worker views of the same live backing store share its identity and index/generation registry. New attachments do not mint new store identities; underlying store close/recreate changes its lifetime identity and fences old views. Test physical-store aliases on supported platforms.
Design
Tantivy storage through Harper. The Harper integration is planned; the native backend is implemented. No production change to base rocksdb-js is required by this work.
Comment generated by kAIle (GPT-6)
Outcome
Implement the Harper integration factory and generation lifecycle after the real storage proof.
Acceptance criteria
Add the planned /harper export only with a tested Harper-owned integration context; no standalone /rocks factory, raw native lease or database path.
Use the same engine, query, commit/reload and error paths as native mode.
Validate qualified Harper integration and persisted-format compatibility before index activation.
Bind handles to the actual store/index/generation; close, drop or recreation invalidates stale contexts.
Drain or fail outstanding native/storage requests safely during worker exit and store shutdown.
Seal/recover abandoned working objects, reclaim orphans and retire generations with bounded crash-safe operations.
Pass real Harper backup/restore, generation swap, storage pressure and close tests; use shared Harper replay/rebuild semantics.
Graceful close keeps storage servicing available until writers finish or roll back, merge tasks exit, searches release slices, and transport requests settle; never synchronously join native work from the JS environment needed to service its storage.
On worker loss or Harper's shutdown deadline expiry, a surviving lifecycle path fails pending requests and wakes native waiters. Cancellation does not prove an executing write stopped or rolled back. Fence late completions and retain request state within the transport budget until the last possible access is gone; a timeout never authorizes freeing live state.
Use Harper's shared close/drop lifecycle and supported storage APIs; prove safe store-view release without new private rocksdb-js close hooks. Test active reads, merge, publication, late responses, and repeated failed teardown without unbounded retained state.
All worker views of the same live backing store share its identity and index/generation registry. New attachments do not mint new store identities; underlying store close/recreate changes its lifetime identity and fences old views. Test physical-store aliases on supported platforms.
Design
Tantivy storage through Harper. The Harper integration is planned; the native backend is implemented. No production change to base rocksdb-js is required by this work.
Comment generated by kAIle (GPT-6)