You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit 31b650d
Browse filesBrowse the repository at this point in the historyBrowse files
fix(usage): key the chart to the calendar the query grouped by
Three review findings, all real.
Densification walked UTC dates while `readUsageTimeSeries` groups by
`date_trunc($bucket, created_at AT TIME ZONE $timezone)` — the viewer's calendar.
For a non-UTC viewer the edge buckets never matched, so their cost stayed in the
headline while their bar read zero. Week and month were worse: Postgres aligns
those to Monday and the 1st, so a cursor stepping from an arbitrary period start
shared no key with the query at all and the whole chart came back zeroed against
a correct total. That is reachable today through an annual enterprise period,
which resolves to `week`.
`densifyUsageSeries` now takes the timezone, derives its first and last bucket
through `Intl.DateTimeFormat('en-CA', { timeZone })`, and truncates both to the
bucket boundary so the keys are the ones `date_trunc` emits. Stepping stays civil
`YYYY-MM-DD` arithmetic — UTC as a proleptic calendar, never converted back to an
instant, so no DST transition can shift a bucket.
The custom-range picker passed `showTime`, so it serialized its end bound as an
inclusive `…T23:59:59` local wall time; the resolver then added a further day.
Every custom range covered 24 hours too many, a legal 92-day selection measured
93 and was rejected, and the wall-clock string parsed as local while the rest of
the window logic is UTC. Dropped `showTime`: a time of day is precision a
day-bucketed panel cannot render, and bare `YYYY-MM-DD` bounds parse as UTC
midnight, which is what makes the half-open `+ DAY_MS` correct.
Admin organization provisioning answered 500 for state it had already committed,
and the existing-membership check then blocked the retry, leaving an organization
no workspace could reach. Attachment is a follow-on effect, not part of creating
the organization, and it is deliberately not folded into the creation
transaction: it runs its own under a lock order that exists to avoid deadlocking
against invitation acceptance, and re-deriving that in a route is how a deadlock
ships. Its failure is now caught and logged, and the endpoint returns the
organization it created.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
0 commit comments