Tombstone horizon with snapshot pinned retention
Skill kjuhwa/skills-hub/skills/algorithms/tombstone-horizon-with-snapshot-pinned-retention
Self-correcting knowledge corpus for Claude Code — 9 stable shape clusters, bias-correction pipeline baked into contribution flow. 47 papers, 45 techniques, 1.1k skills.
npx -y skills add kjuhwa/skills-hub --skill tombstone-horizon-with-snapshot-pinned-retentionAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Tombstones can only be GC'd once no snapshot or reader lease still needs them, tracked via a monotonic horizon watermark.
SKILL.md
1.9 KB, 366 tokens by cl100k_base, as published. Nobody here has run it
tombstone-horizon-with-snapshot-pinned-retention
The naive tombstone GC bug: delete the tombstone as soon as compaction runs, and any in-flight snapshot or replay reader that started before compaction now sees the key resurrect because the original value is gone but the tombstone that hid it is also gone. The fix is a horizon watermark — each active snapshot/reader registers its start offset, and the tombstone-retention horizon is min(registeredOffsets). Compaction may only physically drop a tombstone whose offset is strictly less than the horizon.
Implement as a small registry: snapshots: Map<snapshotId, baseOffset> with register/release, and a derived horizon() that returns the min (or Long.MAX_VALUE if empty). Compaction iterates keys and keeps the tombstone if tombstoneOffset >= horizon(). Two subtle bits: (1) the horizon must be computed before compaction begins and held for the duration — if it advances mid-compaction you're fine (more aggressive), but if it retreats you have a race, so forbid retreats by making release only remove, never replace; (2) long-lived snapshots create unbounded retention, so expose the horizon as a metric and alert when it lags current-tail by too much.
class TombstoneHorizon {
register(id, offset) { snapshots.put(id, offset) }
release(id) { snapshots.remove(id) }
horizon() { return snapshots.values().min() ?? Long.MAX_VALUE }
}
compact(segment) {
h = horizon.snapshot()
for (entry in segment) {
if (entry.isTombstone && entry.offset < h) drop()
else keep()
}
}
Gives 0 of the 12 instructions most analytics metrics skills give in 366 tokens
Counted across 368 of the 369 authors here whose files we hold, read 2026-08-06
- read product marketing context before asking questionsin 18 of 368, across 12 files
- use lowercase with underscores for event namesin 16 of 368, across 6 files
- track events for decisions not vanity metricsin 15 of 368, across 5 files
- use object-action format for event namesin 15 of 368, across 8 files
- produce a tracking plan documentin 14 of 368, across 4 files
- Call RUBE_SEARCH_TOOLS first to get current schemasin 13 of 368, across 2 files
- establish consistent event naming conventions before implementingin 10 of 368, across 4 files
- Verify dimension and metric compatibility before reportingin 9 of 368, across 2 files
- Encrypt data at rest and in transitin 9 of 368, across 3 files
- use snake_case for event namesin 9 of 368, across 5 files
- monitor technical health during the testin 9 of 368, across 5 files
- use consistent property namesin 8 of 368, across 4 files
Said here and by no other author read
- register active snapshot or reader start offset on open
- compute the tombstone retention horizon as the minimum registered offset
- drop a tombstone during compaction only if its offset is below the horizon
- snapshot the horizon before compaction begins and hold it for the duration
- make release remove an entry without replacing or lowering the horizon
- expose the current horizon as a metric
Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.