AI Request Logs: use a fixed 30-day window for the "Last 30 Days" summary period#753
Conversation
The header period labelled "Last 30 Days" filtered the summary cards with a calendar INTERVAL 1 MONTH (28-31 days) while the logs table used a fixed 30-day window, so the two views could report different totals for the same selection. Use INTERVAL 30 DAY in get_date_condition() so the summary matches the label and the table. Adds a regression test asserting the 'month' period spans 30 days.
|
The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message. To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## develop #753 +/- ##
=============================================
+ Coverage 74.45% 76.24% +1.78%
- Complexity 1740 1764 +24
=============================================
Files 85 85
Lines 7521 7589 +68
=============================================
+ Hits 5600 5786 +186
+ Misses 1921 1803 -118
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
…mary period (#753) Fixed - The "Last 30 Days" summary period in the AI Requests Logs page now uses a fixed 30-day window so the summary cards and logs table cover the same span. Co-authored-by: i-anubhav-anand <anubhav24@git.wordpress.org> Co-authored-by: dkotter <dkotter@git.wordpress.org>
What?
Closes #752
Make the "Last 30 Days" summary period (
period=month) use a fixed 30-day window instead of a calendarINTERVAL 1 MONTH, so the summary cards and the logs table cover the same span for that selection.Why?
On the AI Request Logs screen the header dropdown labels this period "Last 30 Days", and the logs table already filters it as a fixed 30 days (computed in the browser). The summary cards, however, build their cutoff server-side with
DATE_SUB(UTC_TIMESTAMP(), INTERVAL 1 MONTH), which spans 28–31 days depending on the date.Because both views are driven by the same dropdown selection, they should cover the same window. With a calendar month they don't: in a 31-day look-back the summary card counts an extra day the table omits; in a February look-back it counts fewer. The fix aligns the summary with the "Last 30 Days" label and the table's window. The other periods already use matching fixed offsets on both sides and are unaffected.
This is the same
get_date_condition()method recently corrected for a UTC mismatch in #671.How?
In
AI_Request_Log_Repository::get_date_condition(), change themonthcase fromINTERVAL 1 MONTHtoINTERVAL 30 DAY. One line; no change to the front end, which already uses 30 days.Use of AI Tools
AI assistance: Yes
Tool(s): Claude Code
Model(s): Claude Opus 4.8 / Sonnet 4.6
Used for: Locating the discrepancy across the PHP/JS boundary and drafting the regression test. I reviewed, ran, and take responsibility for the final change.
Testing Instructions
Automated:
The new test inserts two logs — one 29 days 23 hours old (inside 30 days) and one 30 days 1 hour old (outside) — and asserts
get_summary( 'month' )counts exactly one. It passes with the fix; with the previousINTERVAL 1 MONTHit fails on months whose calendar look-back is not exactly 30 days.Manual:
X-WP-Total) — both now cover the last 30 days.Changelog Entry