feat(scheduled_actions): add nullable timezone column (chat#1881 3c) - #48
feat(scheduled_actions): add nullable timezone column (chat#1881 3c)#48sweetmantech wants to merge 1 commit into
Conversation
… 3c) Adds scheduled_actions.timezone (text, default NULL; NULL = UTC) so the weekly report can be scheduled at 9am LOCAL time instead of 9am UTC. Additive, nullable, backwards-compatible — existing rows keep UTC behavior. Prerequisite for the api-side timezone wiring (api#780 ships the DST-aware time-derivation core). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|
Bugbot is not enabled for your account, so this pull request was not reviewed. Enable Bugbot in the Cursor dashboard to get automatic reviews on future PRs. |
|
Warning Review limit reached
Next review available in: 55 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
Updates to Preview Branch (feat/scheduled-actions-timezone-column) ↗︎
Tasks are run on every commit but only new migration files are pushed.
View logs for this Workflow Run ↗︎. |
![cubic-dev-ai[bot]](https://avatars.githubusercontent.com/in/1082092?s=60&v=4){kind=small}
There was a problem hiding this comment.
1 issue found across 1 file
Prompt for AI agents (unresolved issues)
Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.
<file name="supabase/migrations/20260722000000_add_timezone_to_scheduled_actions.sql">
<violation number="1" location="supabase/migrations/20260722000000_add_timezone_to_scheduled_actions.sql:7">
P2: Invalid timezone values can be persisted and reach timezone-aware `next_run` derivation once API wiring lands, producing errors or incorrect scheduling. Consider enforcing the documented IANA-ID contract at the database boundary (or add a validated timezone domain/function) rather than accepting arbitrary text.</violation>
</file>
Reply with feedback, questions, or to request a fix.
Re-trigger cubic
|
|
||
| -- Change: add optional IANA timezone column with default NULL (NULL = UTC). | ||
| ALTER TABLE public.scheduled_actions | ||
| ADD COLUMN IF NOT EXISTS timezone text DEFAULT NULL; |
There was a problem hiding this comment.
P2: Invalid timezone values can be persisted and reach timezone-aware next_run derivation once API wiring lands, producing errors or incorrect scheduling. Consider enforcing the documented IANA-ID contract at the database boundary (or add a validated timezone domain/function) rather than accepting arbitrary text.
Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. At supabase/migrations/20260722000000_add_timezone_to_scheduled_actions.sql, line 7:
<comment>Invalid timezone values can be persisted and reach timezone-aware `next_run` derivation once API wiring lands, producing errors or incorrect scheduling. Consider enforcing the documented IANA-ID contract at the database boundary (or add a validated timezone domain/function) rather than accepting arbitrary text.</comment>
<file context>
@@ -0,0 +1,10 @@
+
+-- Change: add optional IANA timezone column with default NULL (NULL = UTC).
+ALTER TABLE public.scheduled_actions
+ADD COLUMN IF NOT EXISTS timezone text DEFAULT NULL;
+
+COMMENT ON COLUMN public.scheduled_actions.timezone IS
</file context>
|
Closing as superseded (chat#1881 3c design change). We're reworking api#780 to pass the user's timezone straight to the Trigger.dev schedule ( |
1 participant
What
Prerequisite migration for chat#1881 item 3c (timezone-aware weekly scheduling). Adds
scheduled_actions.timezoneso the weekly-report email can fire at 9am local instead of 9am UTC (currently the middle of the US night).Change
Additive, nullable, backwards-compatible —
NULLmeans UTC, so existing rows keep their current behavior. IANA id (e.g.America/New_York). Mirrors the existingadd_model_to_scheduled_actions/add_trigger_schedule_idcolumn-add migrations.Sequencing (docs → database → api)
Unblocks the api-side wiring: api#780 already ships the tested, DST-aware time-derivation core (
getNextUtcRunForLocalCron); once this column lands, the api PR's follow-up threadstimezonethrough the task contract →createSchedule/next_run. The chat-side timezone picker is a sibling PR. Tracking: chat#1881.Summary by cubic
Add a nullable
timezonetext column topublic.scheduled_actionsto enable timezone‑aware weekly scheduling at 9am local time instead of 9am UTC. Backward‑compatible (NULL = UTC; IANA IDs like America/New_York) and supports chat#1881 item 3c.Written for commit 20f3e0c. Summary will update on new commits.