HarperFast / HarperFast/harper
describe operations omit last_updated_record on RocksDB (RocksTransactionLogStore.getKeys is a TODO stub)
- Dominant language
- JavaScript
- Stars
- 89
- Forks
- 10
- Avg merge
- 2d 2h
- Merged PRs (30d)
- 205
Description
## Summary
`describe_table` / `describe_database` / `describe_all` silently omit `last_updated_record` on RocksDB storage — a regression vs LMDB, where the field is populated from the audit store.
## Cause
`dataLayer/schemaDescribe.ts` computes the field from the audit store's newest key:
```js
for (let key of auditStore.getKeys({ reverse: true, limit: 1 })) {
tableResult.last_updated_record = key[0];
}
```
but `RocksTransactionLogStore.getKeys()` is an unimplemented stub:
```js
getKeys(_options?: any) {
return []; // TODO: implement this
}
```
and the `indices.__updatedtime__` fallback doesn't exist on these tables, so the field is simply never set.
## Impact
- Users of the describe operations lose last-update visibility on RocksDB deployments.
- Downstream, harper-pro's `clone_node` derived its sync-verification targets from this field; all-zero targets made clone sync verification vacuous (clone marks itself Available mid-copy) — see HarperFast/harper-pro#655, which fixes the clone side independently of this issue.
## Implementation notes
There is currently no cheap tail read on the transaction log: rocksdb-js `TransactionLog` only exposes forward `query()` (`_findPosition` is a forward running-maxima index; `getStats().lastCommittedPosition` is a byte position with no timestamp). A small rocksdb-js API — e.g. `getLastEntry()` returning the newest committed entry (or just its timestamp) using the already-tracked last-committed position — would let `RocksTransactionLogStore.getKeys({ reverse: true, limit: 1 })` be implemented per the existing TODO, restoring the describe field.
Contributor guide
Research direction
Read `dataLayer/schemaDescribe.ts` and the `RocksTransactionLogStore.getKeys()` TODO to trace how describe operations obtain the newest audit key. Then inspect rocksdb-js `TransactionLog` and its tracked last-committed position; done means RocksDB describe operations populate `last_updated_record` from the newest committed audit entry, as on LMDB.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- javascript, node.js
- Domain
- databases
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 45/100