[dviejokfs]

Summary

• The "visitors in last 24h" trend badge on the Projects dashboard was showing misleading flat +100%/-100% swings, especially noticeable right after a server restart.
• This affected both analytics backends (Temps supports either TimescaleDB or ClickHouse as the events store, selected via AnalyticsEvents trait impl):
  • TimescaleDB (events_service.rs): the previous-period visitor count was read from the events_hourly continuous aggregate for speed. That aggregate's older buckets are only backfilled by a best-effort async job on startup, and its recurring policy only refreshes the last 3 hours — so right after a restart it can return no row for a project's previous-period window. A missing row was indistinguishable from "genuinely zero visitors."
  • ClickHouse (clickhouse_backend.rs): no staleness issue (it already queries raw events FINAL for both periods), but it had the identical hardcoded fallback, explicitly written to mirror the Timescale implementation.
  • Both paths fed a missing/zero previous count into a fallback that hardcoded the trend to a flat +100.0 (or -100.0), instead of a real percentage or "no data yet."
• Fix:
  • TimescaleDB: query the previous period from the raw events table (same source/index as the current period), eliminating the staleness window entirely.
  • Both backends: stop fabricating +/-100% when there's no real previous-period baseline — omit the trend instead (consistent with the existing both-zero case).
  • Extracted the trend math into a single shared calculate_trend_percentage() (pub(crate) in events_service, reused by clickhouse_backend) so the two backends can't drift into inconsistent semantics again.

Regression tests (testcontainers, real DB/CH — verified live, not just compiled)

• TimescaleDB — test_dashboard_projects_analytics_survives_empty_continuous_aggregate: runs full migrations against a real timescale/timescaledb-ha container but deliberately never calls run_post_migration_backfill, leaving events_hourly completely empty — exactly what a freshly restarted server looks like. Asserts the previous-period count and trend still come out correct (read from raw events), and that a brand-new project with no baseline gets None instead of a fabricated +100%. Passes end-to-end against a live container.
• ClickHouse — ch_dashboard_trend_omits_fabricated_percentage: exercises the same two scenarios against a real clickhouse/clickhouse-server container. Passes end-to-end against a live container.

Bonus: fixed the ClickHouse test harness itself, which uncovered two real pre-existing bugs

Actually running the ClickHouse tests (rather than trusting a compile-only pass) surfaced that setup_clickhouse()'s wait condition was broken and had been silently skipping every ClickHouse test in this file, including the pre-existing ch_backend_full_query_surface — it never once ran against a live container:

• WaitFor::message_on_stdout("Ready for connections") never matches, because clickhouse-server 24.8 writes that message only to its in-container log file, never stdout/stderr. Switched to WaitFor::http("/ping") + a non-empty CLICKHOUSE_PASSWORD, the same fix already applied in temps-otel's ClickHouse tests (added http_wait_plain to this crate's testcontainers dev-dependency to match).

With the harness actually running, two previously-undetected live bugs surfaced and are fixed here too:

• query_events_timeline and query_aggregated_buckets both built WITH FILL ... STEP toInt64(INTERVAL 1 HOUR), which CH 24.8 rejects ("Illegal type IntervalHour of argument of function toInt64") — Interval values aren't toInt64-castable. bucket_ms is a numeric (Unix-ms) column, so STEP needs a plain number; added ch_interval_step_ms() alongside the existing ch_interval() and step by the equivalent millisecond width.
• ch_backend_full_query_surface asserted the migration runner skips exactly 3 migrations on a second run; the list has grown to 6 (0004-0006 added later) and nobody caught the drift since the assertion was never reached.

Test plan

• cargo check --lib --tests -p temps-analytics-events
• cargo clippy -p temps-analytics-events --all-targets — clean
• cargo fmt -p temps-analytics-events -- --check — clean
• cargo test --lib -p temps-analytics-events — 50/50 passed, live, including both new regression tests and the now-repaired pre-existing ClickHouse test, all run against real TimescaleDB/ClickHouse testcontainers (not skipped)

[github-actions]

📓 Changelog preview

This is what your commits will add to the generated CHANGELOG.md at release time (via git-cliff). Do not edit CHANGELOG.md by hand — it is generated from your Conventional Commit messages.

## [Unreleased]

### Fixed

- **analytics:** Stop fabricating +/-100% trend when previous period has no baseline
- **analytics:** Fix same fabricated +/-100% trend in ClickHouse backend
- **analytics:** Fix ClickHouse testcontainer wait + two live SQL bugs

### Testing

- **analytics:** Add testcontainer regression tests for dashboard trend fix