commitFinished finalizes the txn-log entry even when RocksDB Commit() returns a hard error
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 45/100
Research direction
Trace the async-commit execute path around store->commitFinished(...) and TransactionHandle::close(), including the commitAborted path. Compare the status handling with the #668 IsBusy-retry hasLog semantics and review the #694 discussion; done means the visibility and abort behavior for hard Commit() errors is explicitly resolved without exposing uncommitted data.
Written by the indexing model from the issue text.
Description
Surfaced by the #694 review's domain pass; the behavior is pre-existing (preserved verbatim from the legacy libuv commit path) — #694 did not change it.
In the async-commit execute path, store->commitFinished(...) (which advances the committed-read watermark and makes the log entry visible, e.g. to replication) is gated on committedPosition.logSequenceNumber > 0 && !status.IsBusy() — not on status.ok(). If the txn-log writeBatch succeeded but txn->Commit() then fails with a hard non-Busy error (Aborted/IOError), the log entry is still finalized: the transaction log marks an entry committed/visible whose data never committed to RocksDB locally. A replication source could ship an entry it never applied.
Note the interaction with the abort path: TransactionHandle::close() calls store->commitAborted(committedPosition) for non-Committed transactions, which may compensate — the actual visibility window/semantics between commitFinished at execute time and commitAborted at close time needs tracing before changing the gate to status.ok() (the #668 IsBusy-retry hasLog semantics also touch this).
🤖 Generated with Claude Code
- Dominant language
- C++
- Stars
- 24
- Forks
- 3
- Avg merge
- 1d 7h
- Merged PRs (30d)
- 49
Getting set up
- No Dockerfile or Docker Compose file
- No pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from HarperFast/rocksdb-js
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
HarperFast/rocksdb-js#945 ·
Maintainers usually reply within 1 day
-
Difficulty 4/5 3-5 days Newbie friendliness 55/100
HarperFast/rocksdb-js#956 ·
Maintainers usually reply within 1 day
-
Difficulty 5/5 Over a week Newbie friendliness 25/100
HarperFast/rocksdb-js#955 · 1 comment ·
Maintainers usually reply within 1 day
-
Difficulty 5/5 Over a week Newbie friendliness 45/100
HarperFast/rocksdb-js#952 ·
Maintainers usually reply within 1 day
-
Difficulty 4/5 1-2 days Newbie friendliness 45/100
HarperFast/rocksdb-js#946 ·
Maintainers usually reply within 1 day
All issues in HarperFast/rocksdb-js
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 62/100
foxglove/mcap#1907 · 1 comment ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 66/100
Maintainers usually reply within 1 day
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
telegramdesktop/tdesktop#31505 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 1 day
-
ll-builder shell completions omit existing lockfile commands and --lockedPossibly taken @project-nju-learner claimed this today. Open
Difficulty 2/5 1-3 hours Newbie friendliness 90/100
OpenAtom-Linyaps/linyaps#2291 ·
Maintainers usually reply within 1 day