mirror of
https://github.com/multica-ai/multica.git
synced 2026-07-05 13:29:44 +02:00
614dfae884
* docs(timezone): add scheduling/viewing timezone architecture RFC * feat(db): replace daily rollups with task_usage_hourly, add user.timezone Migrations 100-104: add "user".timezone (Viewing tz), build the UTC hourly task_usage_hourly rollup with its pipeline, drop the legacy task_usage_daily / task_usage_dashboard_daily pipelines, and drop the agent_runtime.timezone column. Report queries now slice day boundaries at read time by the caller-supplied @tz instead of materialising in a fixed tz. Regenerate sqlc. * feat(server): add task_usage_hourly backfill command Replace the two legacy backfill commands (daily / dashboard_daily) with a single backfill_task_usage_hourly that loads historical task_usage into the new UTC hourly rollup, sliced per workspace. * refactor(server): resolve viewing timezone in report handlers Report handlers resolve the Viewing tz per request (?tz query param, then user.timezone, then UTC) and pass it to the hourly-rollup queries. Drop the UseDailyRollup feature flags and the old raw-scan/daily-rollup dual paths, remove the /api/usage endpoints, and stop the daemon from reporting and the runtime handler from accepting host timezone. * refactor(core): switch report queries to viewing timezone API client and dashboard/runtime queries send ?tz with each report request, the user schema/types carry the new timezone field, and the runtime timezone field/mutation is removed. * feat(views): add viewing timezone preference and UI Add the useViewingTimezone hook and a Timezone setting in Preferences; report charts and the dashboard week boundary follow the viewer tz. Remove the runtime detail timezone editor and its locale strings. * fix(test): update fixtures and stabilize tests for timezone refactor The timezone architecture refactor changed several types without updating dependent test code: - RuntimeDevice no longer has a timezone field — drop it from the create-agent-dialog runtime fixture. - User now requires a timezone field — add it to the apps/web mockUser fixture. - The PreferencesTab timezone tests asserted on the async save handler (PATCH then store update) with a bare expect, racing the mutation's settle callback, and timed out querying the Select's ~600-option IANA list on a loaded CI runner. Wrap the assertions in waitFor and extend the timeout for those three tests. * docs(timezone): document self-host migration order and trigger invariant Add a SELF-HOST UPGRADE ORDER runbook to the backfill command's package comment: applying migrations 100-104 in a single migrate-up drops the legacy daily rollups before the hourly backfill runs, leaving dashboards empty until cron catches up. Add an INVARIANT comment on trg_atq_dirty_hourly noting that agent_id must be added to the trigger's OF list if it ever becomes mutable, otherwise dirty buckets for the old agent_id are silently missed. * style(runtimes): drop trailing blank line in runtime-detail
33 lines
1.6 KiB
SQL
33 lines
1.6 KiB
SQL
-- Per-user IANA timezone for *viewing* reports — the third leg of the
|
|
-- Operational / Scheduling / Viewing trio (see docs/timezone-architecture-rfc.md).
|
|
--
|
|
-- Distinct from:
|
|
-- * agent_runtime.timezone (Operational): where a runtime physically runs.
|
|
-- That column is dropped later in this migration set — the hour-of-day
|
|
-- activity heatmap now uses the viewer's tz instead.
|
|
-- * autopilot_trigger.timezone (Scheduling): the tz the user had in mind
|
|
-- when authoring a "run at 9am" rule.
|
|
--
|
|
-- This column answers: when this user looks at a dashboard, which calendar
|
|
-- day should "today" be? Two members of the same workspace sitting in
|
|
-- different regions each see their own "today" rendered from the same
|
|
-- underlying UTC data.
|
|
--
|
|
-- NULL means "fall back to the browser-detected tz at render time". New
|
|
-- users land on NULL, so there is no required onboarding step; the
|
|
-- frontend resolves it transparently. A user who explicitly picks an
|
|
-- IANA name in Preferences pins the value here so it survives across
|
|
-- devices and sessions.
|
|
--
|
|
-- This column never affects how data is materialised — all rollups stay
|
|
-- in UTC. It is read-only from the rollup pipeline's perspective and is
|
|
-- only consumed at query time to drive `DATE(bucket_hour AT TIME ZONE @tz)`.
|
|
ALTER TABLE "user"
|
|
ADD COLUMN timezone TEXT NULL;
|
|
|
|
COMMENT ON COLUMN "user".timezone IS
|
|
'User-preferred IANA timezone for report rendering (Viewing tz). '
|
|
'NULL means "use the browser-detected tz at render time". Affects '
|
|
'dashboards, charts, and any "today" label shown to this user. Does '
|
|
'not affect data materialisation — all rollups remain in UTC.';
|