fix(gateway): format usage dates in range timezone#100567
Conversation
|
Codex review: needs maintainer review before merge. Reviewed July 6, 2026, 12:04 AM ET / 04:04 UTC. Summary PR surface: Source +23, Tests +76. Total +99 across 4 files. Reproducibility: yes. The maintainer proof gives a concrete current-main gateway repro for Review metrics: none identified. Merge readiness Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch. Next step before merge
Security Review detailsBest possible solution: Land the focused gateway fix after normal exact-head required checks complete, keeping one canonical date-interpretation path for range boundaries, daily buckets, and response labels. Do we have a high-confidence way to reproduce the issue? Yes. The maintainer proof gives a concrete current-main gateway repro for Is this the best way to solve the issue? Yes. The PR fixes the gateway owner boundary by sharing interpreted calendar-day math for range resolution and response labels; a UI-only relabel would leave the public gateway RPC inconsistent with its own request semantics. AGENTS.md: found and applied where relevant. Codex review notes: model internal, reasoning high; reviewed against bf04d049fa36. Label changesLabel changes:
Label justifications:
Evidence reviewedPR surface: Source +23, Tests +76. Total +99 across 4 files. View PR surface stats
What I checked:
Likely related people:
What the crustacean ranks mean
Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics. How this review workflow works
Review history (3 earlier review cycles) |
|
Reviewed, repaired, and synchronized with current The gateway now uses one calendar-day path for range boundaries and response labels, including gateway-local trailing ranges across DST. Evidence:
No intervening commits on |
0aa9878 to
8971ea2
Compare
8971ea2 to
4a5b3fd
Compare
|
Merged via squash.
|
* fix: format usage date labels by range timezone * fix(gateway): keep usage ranges on calendar days --------- Co-authored-by: NianJiuZst <[email protected]> Co-authored-by: Vincent Koc <[email protected]>
* fix: format usage date labels by range timezone * fix(gateway): keep usage ranges on calendar days --------- Co-authored-by: NianJiuZst <[email protected]> Co-authored-by: Vincent Koc <[email protected]>
What Problem This Solves
Fixes an issue where
sessions.usageresponses could reportstartDate/endDatelabels using UTC calendar days even when the request interpreted the range in a specific UTC offset or gateway-local time.AI-assisted.
Why This Change Was Made
The response date labels now use the same date interpretation as range resolution. When callers provide both explicit dates, the response preserves those calendar labels; otherwise it formats the computed range timestamps through the selected interpretation. This also updates explicit end-date resolution to use calendar day ends for the selected interpretation so gateway-local DST transition days do not query data outside the labelled range.
User Impact
Usage clients in non-UTC offsets can trust that
sessions.usage.startDateandsessions.usage.endDatedescribe the requested local day instead of an adjacent UTC day. Gateway-local explicit ranges on DST-short days also avoid including data from the next local day.Evidence
node scripts/run-vitest.mjs src/gateway/server-methods/usage.sessions-usage.test.ts src/gateway/server-methods/usage.test.tspassed: 4 files, 100 tests.node_modules/.bin/oxfmt --check --threads=1 src/gateway/server-methods/usage.ts src/gateway/server-methods/usage.test.ts src/gateway/server-methods/usage.sessions-usage.test.tspassed.git diff --checkpassed..agents/skills/autoreview/scripts/autoreview --mode localpassed with no accepted/actionable findings after addressing the gateway DST boundary review finding.