35 lines
1.5 KiB
Markdown
35 lines
1.5 KiB
Markdown
# 026 — Settings: maximum logs kept in memory
|
|
|
|
## Summary
|
|
|
|
ottyl currently keeps every ingested log forever in the in-memory `BTreeMap`. The
|
|
wishlist wants a settings-configurable cap on how many logs are retained, with no
|
|
cap (unlimited) as the default.
|
|
|
|
## Scope
|
|
|
|
- New `Settings` field (e.g. `max_logs: Option<usize>`), `None`/unset = unlimited,
|
|
matching the existing "by default it should be unlimited" requirement.
|
|
- Enforce the cap in the engine's ingest path: once the `IngestedLog` range
|
|
exceeds the configured max, evict the oldest entries (lowest `sequence`) to
|
|
bring it back under the cap.
|
|
- Decide and document what happens to data that references evicted logs:
|
|
- Params/metrics already derived into `Bucket` values from an evicted log are
|
|
**not** retroactively removed (buckets are aggregate data, not raw logs) —
|
|
state this explicitly so it's not treated as a bug later.
|
|
- `sequence` numbering does not reset/renumber on eviction.
|
|
- Expose the setting in the Settings API/NavMenu settings panel (a numeric input,
|
|
clearable back to "unlimited").
|
|
|
|
## Acceptance criteria
|
|
|
|
- With no cap configured, behavior is unchanged (unbounded retention, as today).
|
|
- Setting a cap and ingesting past it keeps memory usage bounded — oldest logs
|
|
are evicted, newest `max_logs` remain queryable via `GET /api/logs`.
|
|
- Changing the cap at runtime (via settings) takes effect on the next ingest
|
|
without requiring a restart.
|
|
|
|
## Depends on
|
|
|
|
None — extends the existing `Settings` model.
|