Skip to content

v1.1.1 — retention purge fix

Choose a tag to compare

View all tags
@hett-patell hett-patell released this 25 May 08:44
· 35 commits to main since this release
v1.1.1
e8ec28a

Patch release fixing a critical bug in v1.1's data retention loop.

What broke in v1.1

MaintenancePurge (the 24h retention sweep introduced in v1.1) silently failed on every cycle:

  1. Wrong column name — DELETE FROM ip_enrichment WHERE queried_at < ? referenced a column that does not exist. The actual column is fetched_at. The transaction rolled back, no rows were purged.
  2. Lazy-created tables — ip_enrichment, cowrie_tty_index, and artifacts are created on first write. On a brand-new install the first purge (fired at startup) hit no such table: ip_enrichment and never recovered.

Net effect: every v1.1 install kept growing without bound. The whole point of fix #5 in v1.1 was defeated.

Fix

  • Pre-create the three lazy tables at the start of MaintenancePurge.
  • Use the correct fetched_at column.
  • New test (internal/store/purge_test.go) covers fresh-DB, populated-DB row deletion across all four purged tables, and the zero/negative no-op short circuit.

Other changes

  • migrate_test.go fresh-open assertion bumped v>=3 → v>=4 (stale since the v4 ladder step shipped in v1.1).
  • install.sh SHA256SUMS lookup now uses anchored grep -F + awk $2==b so future suffixed asset names (e.g. -musl) cannot collide.

Upgrading from v1.1

curl -fsSL https://raw.githubusercontent.com/hett-patell/ShardLure/main/scripts/install.sh | sudo bash

Or just download the binary for your arch from the assets below and systemctl restart shardlure-live.

Assets 6
Loading