Skip to content

fix(sentinel): start log retention pruning timer on dynamic enable - #298

Merged
thiagoesteves merged 2 commits into
mainfrom
thiagoesteves/fix-log-retention-timer
Aug 14, 2026
Merged

fix(sentinel): start log retention pruning timer on dynamic enable#298
thiagoesteves merged 2 commits into
mainfrom
thiagoesteves/fix-log-retention-timer

Conversation

@thiagoesteves

@thiagoesteves thiagoesteves commented Aug 13, 2026

Copy link
Copy Markdown
Owner

Summary

  • The pruning timer was only started in init/1 when data_retention_period was non-nil. The handle_cast({:update_data_retention_period, ...}) callback updated the retention period in state but never started the timer if it was not already running. So if log retention was initially disabled (nil) and then enabled via a config change through the watcher, old log entries were never pruned.
  • Track the timer reference in state. Start the timer when transitioning from nil to a non-nil retention period, and cancel it when transitioning back to nil.

Test plan

  • mix test apps/sentinel/test/logs/server_test.exs --warnings-as-errors (13 tests)
  • mix format --check-formatted
  • mix credo --strict apps/sentinel/lib/sentinel/logs/server.ex

Risk assessment

  • Impact: Log retention now works correctly when enabled at runtime via config changes, not just when set at startup.
  • Blast radius: Sentinel logs server only; the prune timer lifecycle is the only behavior change.
  • Regression risk: Low - existing behavior (timer started in init) is preserved; the new code only adds start/cancel on dynamic updates.
  • Rollback: Plain commit revert.

Generated with Devin powered by GLM-5.2 High

@thiagoesteves thiagoesteves self-assigned this Aug 14, 2026
The pruning timer was only started in init/1 when data_retention_period
was non-nil. The handle_cast({:update_data_retention_period, ...})
callback updated the retention period in state but never started the
timer if it was not already running. So if log retention was initially
disabled (nil) and then enabled via a config change through the watcher,
old log entries were never pruned.

Track the timer reference in state. Start the timer when transitioning
from nil to a non-nil retention period, and cancel it when transitioning
back to nil.

Risk assessment:
- Impact: Log retention now works correctly when enabled at runtime via
  config changes, not just when set at startup
- Blast radius: sentinel logs server only; the prune timer lifecycle is
  the only behavior change
- Regression risk: low - existing behavior (timer started in init) is
  preserved; the new code only adds start/cancel on dynamic updates
- Rollback: plain commit revert
@thiagoesteves
thiagoesteves force-pushed the thiagoesteves/fix-log-retention-timer branch from 6573bfa to 04bf3c1 Compare August 14, 2026 12:16
@thiagoesteves
thiagoesteves merged commit 79fbede into main Aug 14, 2026
1 check passed
@thiagoesteves
thiagoesteves deleted the thiagoesteves/fix-log-retention-timer branch August 14, 2026 12:22
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant