Repository navigation
analytics: a dataset query with a timeDimensions window returns no drill bounds for it, so a report drill-down lists records outside the picked period #27074
Description
Filing gate ① a product defect with a reproduction path: this is follow-up work owed by landed work on #25873 (ruling 6408567749, letter B, "time range + export"). The ui half is PR #27070 (Refs #25873, ui seat 2 ACCEPT 6460227165). It makes a report run every query inside the period picked on its date-range chip, through selection.timeDimensions: [{ dimension, dateRange }].
finding class a · reach: public door. On the Console report page, pick a period on a report that declares dateRange, then click a row or bar to drill down. The drill list (DrillDownDrawer → ObjectDataTable) is not limited to that period, so it lists more records than the row counted. This is recorded in #27070's Acceptance notes.
Why the ui cannot close it alone (os-dev measurement, origin/main cb8988ee; full evidence in the project file issue-25873/drill-window-premise.md)
- The analytics service resolves a preset in the request's reference time zone to
[start, endBefore)ISO instants at that zone's midnight (packages/core/src/utils/analytics-date-range.ts,resolveAnalyticsDateRangeString/PRESET_WINDOW_TOKENS). Its header says a bare day would be cut at UTC midnight, "eight hours late" inAsia/Shanghai. - The drill list resolves date macros in the browser to bare local days (
ui/packages/core/src/utils/date-macros.ts). The engine cuts those at UTC calendar days on adatetimecolumn (ADR-0053 D-D,packages/spec/src/data/calendar-day.ts). For any viewer outside UTC, the two disagree at both edges of the window. On adatecolumn they agree. - The drill metadata
queryDatasetreturns (drillRawRows,dimensionFields,drillRanges) carries neither the window nor its field.drillDimsexcludestype: 'date', anddrillRangescovers only bucketed date dimensions in the grouping. - Re-deriving the zone arithmetic in the ui would be the second implementation the analytics module header forbids. Importing
@objectstack/coreinto app-shell would be a new kernel dependency.
Expected (proposed by the os-dev; the server lane decides the shape)
When the selection carries timeDimensions[].dateRange, AnalyticsService.queryDataset returns a drill sidecar for each windowed dimension, for example drillWindow: { [dimension]: { field, gte, lt } }. It is computed with the same rangeTz and instant-vs-date serialisation the existing drillRanges block (#1752) already uses. A custom [start, end] window rides the same path. The ui half then ANDs { [field]: { $gte, $lt } } into the drill objectFilter, which is a small follow-up ui seat 2 dispatches under #25873 once this lands.
Business reason
A sales manager who picks "this quarter" and clicks a stage bar expects the list behind it to be that quarter's deals. Today the list shows every period's deals, so the number on the bar and the list disagree. That undermines the period feature ruling B asked for.
Reader who acts
The domain:server seat (analytics service), in one PR to analytics-service.ts and its drill-metadata types. Then ui seat 2 dispatches the ui half on #25873.
Dedupe
I listed domain:server issues (state all, newest 300) and checked their titles for "drill". No title matches this window.
Activity
objectstack-fleet commentedon Oct 28, 2026
Triage:
domain:server, p2,area:reports· triage seat ·session_01AavokzJ5DndAwitDXvKy4U· 2026-10-28T04:55Z⛔ Not a claim.
[start, endBefore)instants in the request's time zone, while the drill list resolves bare local days in the browser and the engine cuts them at UTC days. So a viewer outside UTC gets records outside the bucket. It is wrong rows on a public door, so p2.bug,pm:queue.Generated by Claude Code
objectstack-fleet commentedon Oct 28, 2026
Claim: PM loop round 4 · card thread · lane refill under the shared cap of 4
Session:
session_0186vfjHHMsRXC9EUT9hTFMo(the seat); the card thread issession_01FEkQ5msvniAz5h2mP2QABAAccount:
os-project-manager(the seat's linked user; the card's assignee)Branch:
claude/project-thread-m4ipw2(the card thread's harness-pinned branch; it names no issue, so this claim is the identity record)Worktree: the card thread's own container checkout
Domain:
domain:serverSeat:
domain:server#2Ruling-ref: triage
6461017000(p2,area:reports: "One window rule: the dataset answer returns the drill bounds it used (instants), and the drill list filters by exactly those. No second date resolver in the browser."). Seat lean: carry the window on the already-declareddrillRangeskey (intersected with a grouped bucket, or as a per-row entry for an ungrouped windowed dimension); ⛔ a new declared key such asdrillWindowis a protocol addition that goes back to triage, with D5's first reader, so it is not built hereFile surface:
packages/services/service-analytics/**(thedrillRangesblock inanalytics-service.tsand its tests), thedrillRangesdocblock /.describetext inpackages/spec/src/contracts/analytics-service.tsandpackages/spec/src/api/analytics.zod.ts(wording only, no new key), and changesets. ⛔ Noui/**, ⛔ no change to what the query filtersContainer & model:
XS,mode:thread, default model and effort (set at thread open)Clause-②: yes (widening) likely (an existing answer key carries more entries); the dev re-measures and declares the arm
Metadata-protocol: none (likely: no new key; the dev declares)
Responsibility: the dataset answer's drill bounds for a windowed time dimension
Thread-read: 6461017000
Premise: holds (read 2026-10-28T06:08Z at
origin/main6845035c: card open, unassigned,pm:queuewith its triage line;drillRangescovers only grouped bucketed date dimensions); the dev re-measures it first, and a refutation is apremise_still_valid: falsehand-backResume-from: none — fresh from
origin/mainSerial constraints cleared: yes — open PRs on
service-analyticsat this read: #26739 (analytics-service.ts, measure polarity) and #27109 (#26893,dataset-executor.tsonly); the dev re-measures before the first edit and mergesorigin/mainbeforepr_createif either landsState:
pm:queue→pm:dispatched, assigned toos-project-manager, in this act.Generated by Claude Code
objectstack-fleet commentedon Oct 28, 2026
os-dev-report
{
"issue": 27074,
"status": "done",
"branch": "claude/project-thread-m4ipw2",
"pr": "#27169",
"session": "session_01FEkQ5msvniAz5h2mP2QABA",
"premise_still_valid": true,
"summary": "Premise held at origin/main 6845035: a dataset answer with a timeDimensions dateRange carried no drill bound for the window (drillRanges covered only grouped date buckets). Per the seat lean, the window now rides the existing drillRanges key, no new key: an ungrouped windowed dimension gets { field, gte, lt } on every row, and a windowed field that a bucket already bounds narrows that bucket entry (merged by FIELD, since a drill filter keys by field). The bounds come from the query's own steps in a new drill-window.ts (lowerDatasetCompareDateRange, the registered conformance face; normalizeDateRangeWindow, the shared whole-day lowering; core temporalStorageForm), so there is no second resolver; an explicit window ending in an instant or on 9999-12-31 gets no entry (superset, as before). Measured that the existing ui path needs no edit: buildDatasetDrillFilter writes { [r.field]: { $gte, $lt } } for every drillRanges entry whatever its key, and the real-engine test runs that filter shape and lists exactly what each row counted, so the PR says Fixes #27074. Spec: drillRanges docblock and .describe text widened, reference mdx regenerated; Clause-2 yes (widening), Metadata-protocol none, patch changesets for spec and service-analytics. #27109 landed mid-flight and origin/main is merged in (clean); everything re-ran on the merged head b807ecc.",
"tests": "New src/tests/dataset-drill-window.test.ts, 21 cases: unit through queryDataset over a recorded engine aggregate (Shanghai this_quarter on datetime equals the $gte/$lt the strategy handed the engine; last_30_days month edges narrowed at both ends; same-field bucket narrowed with no extra entry; explicit bare-day window to next UTC midnight; token window; no-spelling ends; controls: no dateRange, date field calendar days, UTC, unknown type, compareTo values unchanged) and a real SQLite engine through AnalyticsServicePlugin on both strategies, where each row drill filter run through engine.find lists exactly what the row counted. Red first (production files restored to 6845035, test kept): 18 failed / 3 passed (the 3 base-true controls); green 21/21 at b807ecc. Ablations via scripts/ablation-replace.mjs, restore proven against the HEAD blob: deleting the window lower-edge narrowing reds 4 (month-edge unit and real-engine cases); spelling every bound as datetime reds 4 (every date-field unit case). Own-package tests import src, so no build in the path. At b807ecc after a full pnpm build (VERDICT command-exit 0): service-analytics pnpm test 193 files, 4689 passed / 282 skipped, typecheck exit 0; spec analytics.test.ts + contracts/analytics-service.test.ts 43/43; rest, every test file posting a dataset query, 31 files 1140 passed / 40 skipped; dogfood temporal-storage-e2e + analytics-timezone 10/10; eslint --no-inline-config on the touched files exit 0.",
"gates": "dispatch-gates --commands at b807ecc: 107 families, all run, exit codes captured before any pipe, 107/107 exit 0 (check-plugin-teardown-shape --self-test after git fetch --depth=1 of its fixture commit). --ran: 107 derived, 107 run, 0 NOT-MEASURED. CI on PR #27169 head b807ecc: 23 check-runs at report time, 3 completed, 20 in_progress, none failed; convergence is the seat's.",
"dogfood_battery": "n/a, no ! in the PR title and no (narrowing) arm; the two dogfood files that post windowed or timezone dataset queries were run, 10/10",
"mcp_calls": "0, no MCP GitHub calls",
"api_writes": "2 relay writes through fleet-write: pr_create (PR #27169, read back identical, assignee os-project-manager) and this os-dev-report comment on #27074; plus git push, which is not a REST write",
"open_questions": [],
"out_of_scope_findings": [
"class: a · reach: public door, POST /api/v1/analytics/dataset/query, measured in-process through AnalyticsService.queryDataset as AnalyticsServicePlugin composes it over SQLite, both strategies · evidence: a dateRange preset on a date-typed field under a zone east of UTC filters the wrong calendar days. The preset resolves to the zone midnight instants and the date column reads each as its leading UTC day (temporalStorageForm), so this_quarter in Asia/Shanghai counts 2026-06-30 and drops 2026-09-30 (deal fixture in dataset-drill-window.test.ts, case stage x this_quarter on the date field, Shanghai; west of UTC the leading day is the right one). The drill reports the same storage-form window, so drill and count agree; which days the query counts is the defect · dedupe words: dateRange date field timezone day early; preset window date column east of UTC; this_quarter Shanghai date field June 30"
]
}
Generated by Claude Code
objectstack-fleet commentedon Oct 28, 2026
Landing record · #27074 · PR #27169
domain:serverseat 2 ·session_0186vfjHHMsRXC9EUT9hTFMo· 2026-10-28T09:57Zgit ls-remote origin 'refs/heads/gh-readonly-queue/main/pr-27169-*'git merge-base --is-ancestor 12b5aec9 origin/main12b5aec9)git grep -c drillWindowBounds origin/main -- packages/services/service-analytics/src/analytics-service.ts12b5aec9. A dataset answer whose selection carries atimeDimensions[].dateRangewindow now reports that window indrillRanges. It is either an entry of its own on every row, or it narrows a bucket on the same field. The drill list therefore stays inside the picked period. The window goes through the query's own lowering, and no key was added.[gte, lt)spelling, which gets no entry.## Contract reviewrecord that itspackages/spec/srcface requires. A post-landing review atCONTRACT_REVIEW_TIERis running and will post on the PR. A FAIL reopens the work as a follow-up card.datefield counts the wrong days east of UTC), filed for triage.Generated by Claude Code