Repository navigation
fix(calendar): reject invalid time windows before querying events - #1298
Conversation
|
🦞👀 Pull request received. I will update this pull request when review starts. ClawSweeper review completeClawSweeper finished reviewing this revision. The review result is being finalized. |
There was a problem hiding this comment.
Copilot was unable to review this pull request because the user who requested the review has insufficient remaining quota. Try requesting a review at a lower effort level.
An organization owner can choose the repository organization as the billing source for reviews requested by members with a paid Copilot license. Learn about Copilot code review billing.
|
Codex review: blocked before merge. What this changesThis PR anchors open-ended searches to their explicit start, rejects invalid resolved windows, and preserves historical timezone instants in requests. Example: Run gog calendar search meeting --from 2099-01-01T00:00:00Z.
Review scores
ProductKind: Bug fix · Worth it: Needs a maintainer decision · Fix scope: Complete Merge readiness⛔ Blocked before merge - 1 item remains This PR repairs a current Calendar bug without a definite implementation defect, but the changed default for successful past-start searches still needs an owner decision. Priority: P2 Decision needed
Before merge
FindingsNone. Agent review detailsHow this fits togetherCalendar commands pass date flags through shared timezone-aware range resolution and formatting before querying Google Calendar and printing events or availability. flowchart LR
A[Calendar CLI flags] --> B[Calendar command]
B --> C[Timezone and range resolver]
C --> D[Request timestamp formatter]
D --> E[Google Calendar API]
E --> F[Events or availability output]
Technical reviewBest possible solution: Keep the shared range validation and instant-preserving formatter, and settle the explicit-start search default before landing. Do we have a high-confidence way to reproduce the issue? Current-main source establishes both invalid-window paths, and the contributor supplies exact release-versus-head CLI request bounds and exit codes; this read-only review ran no target code. Is this the best way to solve the issue? The implementation uses existing owners and mechanisms with focused command regressions; its broader change to successful search windows is a product choice rather than a demonstrated code defect. AGENTS.md: found and applied where relevant. Codex review notes: model internal, reasoning medium; reviewed against dc6bf1f3bba8. Provenance checked
TestingProof path: shipped entry point. SecurityNone. EvidenceWhat I checked:
Likely related people:
Preflight sourceSource unknown. Source comparison at the observed PR snapshot only. Completion is self-reported; body, policy, tests, execution, and report bytes are not verified. LabelsLabel changes:
Label justifications:
Rank-up movesOptional improvements that raise the rating; they are not merge blockers.
Rating scale6/6 🦀 challenger crab · 5/6 🦞 diamond lobster · 4/6 🐚 platinum hermit · 3/6 🦐 gold shrimp · 2/6 🦪 silver shellfish · 1/6 🧂 unranked krab. Overall follows the weaker of proof and patch quality; ✨ marks media proof (a screenshot, video, or linked artifact) that directly shows the changed behavior. WorkflowClawSweeper edits this one comment on every review. Comment HistoryReview history (1 earlier review cycle)
Reviewed November 4, 2026, 10:56 PM ET / November 5, 2026, 03:56 UTC (Revision 2). |
|
@clawsweeper re-review |
|
🦞👀 Re-review progress:
|
…arches Reject equal or reversed Calendar windows with a usage error before requesting events, and make a far-future search with only --from usable by ending it 90 days after that start. Successful historical --from-only searches retain their existing end at now + 90 days. Explicit time ranges and historical timezone offsets keep their intended instants. Closes openclaw#1280. Validation: synthetic Calendar HTTP regressions fail on the old implementation for far-future searches, invalid ranges, and historical offset seconds. The focused Calendar suite passes, including a compatibility regression for historical open-ended searches. No live Google Calendar data was used. Full gate: `make ci` passed on the dedicated Linux Crabbox lease (run `run_5b7894aafd5fe2d0f467bb6b930a7f50`). Independent Codex P0–P2 final review is clean. Co-authored-by: Steven Huang <[email protected]>
fd0f838 to
efd1e0c
Compare
|
Landed in #1298 as 9ed5c36. Equal/reversed serialized windows now fail as usage errors before the Events request. Far-future --from-only searches get a valid default end, while successful historical searches retain their previous now + 90 days upper bound. The regressions fail on the old implementation; focused synthetic Calendar tests, full |
Reject equal or reversed Calendar windows with a usage error before requesting events, and make a far-future search with only --from usable by ending it 90 days after that start. Successful historical --from-only searches retain their existing end at now + 90 days. Explicit time ranges and historical timezone offsets keep their intended instants.
Closes #1280.
Validation: synthetic Calendar HTTP regressions fail on the old implementation for far-future searches, invalid ranges, and historical offset seconds. The focused Calendar suite passes, including a compatibility regression for historical open-ended searches. No live Google Calendar data was used.
Full gate:
make cipassed on the dedicated Linux Crabbox lease (runrun_5b7894aafd5fe2d0f467bb6b930a7f50). Independent Codex P0–P2 final review is clean.Co-authored-by: Steven Huang [email protected]