Problem
Calling get_topic_timeline(topic_name="sap", bucket="week") returns one row per distinct calendar day an item exists for that topic, not one row per calendar week. Evidence: the result spans from 2006-10-04 through 2026-08-21, with 34 individual daily timestamps (2026-08-04, 2026-08-05, 2026-08-06, 2026-08-07 all appear as separate rows), never collapsed into week-spanning buckets. The same call against "servicenow" shows the identical pattern: individual dates (2020-07-29, 2024-05-10, 2026-08-18 through 2026-08-22) rather than weekly aggregates.
Why it wasn't caught in initial testing
A first test against "fair work commission" looked correct, its results happened to all fall within a single calendar week (17-21 Aug), so daily and weekly grouping produced visually identical output by coincidence. The bug only became visible once a topic ("sap") with a multi-year spread was tested, at which point per-day granularity going back to 2006 makes it unambiguous that no aggregation is happening.
Likely cause
The bucket parameter is probably accepted but not wired into the underlying date-truncation logic (e.g. a DATE_TRUNC('day', ...) or equivalent is running regardless of whether week or month was requested, rather than switching truncation granularity based on the parameter).
Fix
Ensure bucket: "week" truncates each item's date to its containing calendar week (or ISO week) before grouping/counting, and bucket: "month" truncates to month, rather than grouping by the raw date in both cases. Worth a regression test with a topic whose items span more than one bucket period, a single-week topic will always pass regardless of whether the bug is present, which is exactly how this shipped unnoticed.
Problem
Calling
get_topic_timeline(topic_name="sap", bucket="week")returns one row per distinct calendar day an item exists for that topic, not one row per calendar week. Evidence: the result spans from 2006-10-04 through 2026-08-21, with 34 individual daily timestamps (2026-08-04, 2026-08-05, 2026-08-06, 2026-08-07 all appear as separate rows), never collapsed into week-spanning buckets. The same call against "servicenow" shows the identical pattern: individual dates (2020-07-29, 2024-05-10, 2026-08-18 through 2026-08-22) rather than weekly aggregates.Why it wasn't caught in initial testing
A first test against "fair work commission" looked correct, its results happened to all fall within a single calendar week (17-21 Aug), so daily and weekly grouping produced visually identical output by coincidence. The bug only became visible once a topic ("sap") with a multi-year spread was tested, at which point per-day granularity going back to 2006 makes it unambiguous that no aggregation is happening.
Likely cause
The
bucketparameter is probably accepted but not wired into the underlying date-truncation logic (e.g. aDATE_TRUNC('day', ...)or equivalent is running regardless of whetherweekormonthwas requested, rather than switching truncation granularity based on the parameter).Fix
Ensure
bucket: "week"truncates each item's date to its containing calendar week (or ISO week) before grouping/counting, andbucket: "month"truncates to month, rather than grouping by the raw date in both cases. Worth a regression test with a topic whose items span more than one bucket period, a single-week topic will always pass regardless of whether the bug is present, which is exactly how this shipped unnoticed.