fix(daemon): flush the aggregator by the longest window — hourly tiers regain their history (#610)

[evertramos]

What & why

Closes #610 (Phase 2 of #605, invariant C3).

runFlush evicted every in-memory event older than Windows()[last]. Windows() is in rule order, and the embedded rules end with the mail rules' 300 s window, so every 10-minute flush cut the history to 5 minutes. Every hourly *_sustained rule (http_wp_probe_sustained 10/1h, http_xmlrpc_sustained, http_scanner_sustained, ssh_bruteforce_sustained, the mail/vaultwarden/nextcloud/keycloak sustained tiers) could see at most one flush interval — an attacker pacing one attempt every 5 minutes was invisible to the tier that exists for that pacing.

Acceptance criteria restated:

• Harness, virtual clock: 9 wp-login.php hits one every 5 min with the 10-min flush tick in between, 10th at +45 min → http_wp_probe_sustained bans (TestDetection_HourlyTierSurvivesFlush; fails on dev before the fix, commit 1 of this PR).
• Benchmark coverage of the flush: deferred to fix(bench): the benchmark flush is a no-op (no long-window split) and the corpus has no hour-scale legit scenario #623 — the bench builds its aggregator from every rule window (no long-window split), so a flush at MaxWindow() (7 days) is inert there; the earlier commit that added it was removed after the adversarial review (F3).

Changes

• internal/aggregate: MaxWindow() (the value New already computed).
• internal/daemon/daemon.go: runFlush body factored into flushAggregates(ctx, now); cutoff is now - MaxWindow().
• internal/daemon/harness.go: FlushOnce seam; internal/e2e: httpHit helper + the scenario.
• internal/daemon/flush_test.go: unit regression (skips if the rule order no longer has the bug shape).
• docs/internal/INVARIANTS.md: C3 gap marked fixed.

Tests

• Unit tests added/updated
• New parser/rule? fixture — N/A
• Parser change? fuzz — N/A
• make lint test green locally (-race): go test -race ./... ok; go test -tags bench ./internal/bench/ ok; gofmt -l . empty; go vet ./... ok; golangci-lint run ./... (v2 image) 0 issues; ip-hygiene gate clean.

Blast radius (per docs/internal/INVARIANTS.md)

• Invariant(s): C3 (rules fire on exactly the events they claim); touches the aggregator eviction horizon only.
• Other readers/writers re-verified: Aggregator.Add eviction already used maxWindow (unchanged, aggregate_test); evaluateRules/Aggregate(ip, w, now) per window unchanged (lowslow_test, httplowslow_test, e2e A scenarios); PruneEventCounts horizon unchanged (long windows, lowslow_test).
• Adversarial review findings (filed, not fixed here): entries now live up to 1 h instead of ~5–15 min and the per-IP bucket has no entry cap — a 100 req/s client-hour ≈ 250–360 MB and ~9 ms per read under the aggregator lock (fix(aggregate): per-IP entry retention is unbounded — one busy client costs hundreds of MB and most of a core with the 1 h horizon #622, high). With the hourly tier alive, evidence already consumed by a strike re-fires the ladder on the next request after the 5-min ban expires, including on benign traffic and legit integrations (fix(decision): strike ladder re-fires on evidence already consumed by a strike — hourly tiers escalate on a benign request after the 5-minute ban expires #621, high — must land before the batch rc). Future-dated events block eviction (fix(aggregate): a future-dated event blocks eviction and pins the LRU bucket #624). DefaultMaxSamples bounds the read-side sample only, not memory.
• Harness scenario that failed before the fix: internal/e2e.TestDetection_HourlyTierSurvivesFlush.

Security review (per docs/internal/SECURITY-REVIEW.md)

• §1 Input handling: N/A.
• §2 Decision engine (lock-out / false-ban): FINDING (filed as fix(decision): strike ladder re-fires on evidence already consumed by a strike — hourly tiers escalate on a benign request after the 5-minute ban expires #621) — the hourly tier was effectively dead in production, so restoring it changes decision-engine behaviour: after a strike-1 ban (5 min) expires the same hour of evidence earns strike 2 on the next request, and the hourly WordPress/xmlrpc/404 rules match on path/status only, so an admin logging in 10 times in an hour, a Jetpack xmlrpc integration at 9/h, or an office NAT with a missing favicon (60 404/h) reach strike 1 and then 2. The flush fix is correct and necessary; fix(decision): strike ladder re-fires on evidence already consumed by a strike — hourly tiers escalate on a benign request after the 5-minute ban expires #621 must ship in the same batch before any release candidate carries this.
• §3 Privilege separation / enforcer: N/A. §4 Secrets: N/A. §5 AI: N/A. §6 Control surfaces: N/A. §7 Plugins: N/A. §8 Edge: N/A. §9 Dependencies: none.
• §10 Logging / audit / fail-safe: OK — unchanged. §10 self-review walked (no dead branch; flushAggregates pure refactor plus the horizon change).

Self-assessment: no step toward lock-out, injection, privilege escalation, secret exfiltration or evasion — it removes an evasion (pacing under the hourly tier).

Checklist

• Follows AGENTS.md Hard Rules
• No hardening systemd directive removed
• Docs updated (INVARIANTS.md; user docs already describe the hourly tiers as working)
• New dependency justified (none)

🤖 Generated with Claude Code

https://claude.ai/code/session_01KCu1p3UrUGSzWVwhNuJ47k

[strix-security]

Strix is installed on this repository, but we couldn't run this PR security review because this workspace's trial has ended. Add a card to resume code reviews here.

So far, Strix has reviewed 49 pull requests, surfaced 8 security issues (1 critical/high) and blocked 3 risky merges across this workspace.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[amazon-q-developer]

The fix correctly addresses issue #610 by ensuring the aggregator flush uses the longest configured window rather than the last window in rule order. The implementation is sound with comprehensive test coverage including unit tests, E2E tests, and benchmark updates. The changes properly restore the intended behavior where hourly detection rules can see their full hour of history instead of being limited to 5-10 minutes.

---

You can now have the agent implement changes and create commits directly on your pull request's source branch. Simply comment with /q followed by your request in natural language to ask the agent to make changes.