HarperFast / HarperFast/harper

[Epic] TTL & record expiration correctness

Open
#2,116 0 comments 0 reactions 0 assignees View on GitHub
Dominant language
JavaScript
Stars
89
Forks
10
Avg merge
2d 6h
Merged PRs (30d)
200

Description

Record expiration and TTL: the eviction path, the accounting behind it, and what happens when an expiration value is wrong.

## Scope

**In:** TTL/expiration configuration and validation, the eviction and cleanup path, whether expired records actually stop being returned, and the disk/memory accounting of records past their expiry.

**Out:** transaction-log and audit retention (harper#2115) — related in spirit, different mechanism and different config surface.

## Why

Two of the members fail in ways that look nothing alike but share a cause: expiration values reach the storage layer without having been validated against what that layer accepts, and expired records are treated as gone by one layer while another still returns them. Both are the kind of defect that reads as a leak until you look closely.

_Created during backlog triage. Child issues keep their own priorities and milestones._

Contributor guide

Open the contributing guide

Research direction

This is an epic rather than a self-contained change, and it names no files, tests, or entry points. Begin by reviewing the child issues covering TTL validation, eviction and cleanup, expired-record reads, and disk/memory accounting; the epic is complete when those cases are addressed while transaction-log and audit retention remain out of scope.

Written by the indexing model from the issue text.

Assessment

Tech stack
javascript, nodejs
Domain
databases, performance
Issue type
Bug
Difficulty
5/5
Estimated time
Over a week
Activity status
Quiet
Clarity
Needs clarification
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.