Repository navigation
fix(query): accept d/w suffixes in time_range, reject bad input - #292
Conversation
ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Free Run ID: 📒 Files selected for processing (1)
📝 WalkthroughSummary by CodeRabbit
WalkthroughThis PR adds day/week duration suffixes to time range parameters, making ChangesTime Range Parsing Enhancement
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Note 🎁 Summarized by CodeRabbit FreeYour organization is on the Free plan. CodeRabbit will generate a high-level summary and a walkthrough for each pull request. For a comprehensive line-by-line review, please upgrade your subscription to CodeRabbit Pro by visiting https://app.coderabbit.ai/login. Comment |
|
📚 Docs preview is live: https://12e06032-wavehouse-docs.wave-rf.workers.dev Updated for commit 365232d |
Merging origin/main (#292) closed #285 — `7d`/`2w` now resolve to hours in the structured-query builder, so two rationale comments that justified "168h, not 7d, because #285" are now false: - LiveDemo.astro:259 — fallback comment's `("168h" not "7d" — see #285.)` - CHANGELOG.md — the live-demo entry's `(168h, since day-suffixed durations are #285)` The `168h` literal in the fallback query is unchanged (an explicit hours value is still perfectly valid); only the obsolete justification is removed. Flagged by the pre-push code review after the merge. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Summary
time_range.since/untilaccept relative durations andsdk.mdadvertises day suffixes (7d), but Go'stime.ParseDurationstops at hours — so"7d"failed to parse and fell through to ClickHouse as a rawDateTimeliteral, surfacing as an opaqueCannot read DateTimeerror (a retryable 500, per #271). This fixes it in the structured-query builder:resolveTimeValuepre-expandsNd→N*24handNw→N*168h(7d→168h,2w→336h,1d12h→24h12h) beforetime.ParseDuration, so the documented ranges resolve correctly.resolveTimeValuenow returns an error for any value that is neither a relative duration nor an RFC3339 timestamp, andBuildmaps it to a400with a clear message instead of handing a raw string to ClickHouse.Test plan
TestExpandDayWeek,TestResolveTimeValue_DayWeekSuffix,TestResolveTimeValue_Invalid, and aBuild-levelinvalid time range since durationcase; updated the three existingresolveTimeValuetests for the new(string, error)signaturePOST /v1/querywithtime_range.since: "7d"returns rows;"banana"returns400Related Issues
Closes #285
Relates to #271 (opaque ClickHouse error →
400)