Repository navigation
Unconfirmed observation: the dashboard dateRange "Custom…" option did not open a picker under automation — needs a re-drive on a current console build before it is treated as a defect #7570
Description
Symptom
Read this first: this is an unconfirmed observation, not a reproduced defect. The dashboards run deliberately did not file it as a bug — it was recorded as something to re-check, and this card exists only so the re-check is not lost. Nothing here asserts broken behaviour.
While driving the dashboards area, selecting "Custom…" in a dateRange global filter did not appear to open a date-range picker under browser automation. Expected: the custom-range picker opens and accepts an explicit start/end window.
What makes it weak evidence, stated plainly:
- observed under automation only, with no manual confirmation;
- not reproduced, and no repeat-count recorded;
- the console under test was the vendored build (
09987b68), which is many commits behind objectuiorigin/main— in the same run the vendored pin was found to trailorigin/mainby 138 commits; - a picker that fails to open under automation is a classic driver/timing artifact (portal-rendered popovers, animation settling), which is exactly why the run declined to call it.
The rest of the dateRange surface behaved (the dashboards run's global-filter and drill-through items passed, including half-open month bounds on drill).
Root cause
Not located by the run. No source was inspected for this observation, and no failing selector or console error was captured.
Reproduction
Not established — establishing it is the work. Required next step:
- Re-drive the "Custom…" option of a
dateRangeglobal filter against a current console build (objectuiorigin/main, not the vendored09987b68pin), in a fresh browser session. - Drive it manually as well as under automation, so a driver artifact can be told apart from a real failure.
- If it reproduces on a current build, it becomes a real defect and the card belongs in objectui (console date-range filter control) with the captured evidence — this card is not that card.
- If it does not reproduce, close this as an automation artifact and note it, so the next run does not re-litigate it.
No domain:* lane is applied: there is nothing to fix in this repo unless step 3 lands, and if it does, the fix is cross-repo in objectui.
Activity
os-zhuang commentedon Aug 11, 2026
Triage: graded
finding(held); removed the co-appliedpm:queue— the card arrived carrying both, which is a half-state (finding= held observation,pm:queue= dispatchable; they are exclusive). The card's own first line rules the grade: "this is an unconfirmed observation, not a reproduced defect", observed once, under automation only, against a vendored console 138 commits behind objectui main. Grading is the triage seat's single channel, and the card is unassigned and undispatched, so this touches no claim.domain:*/repo:*, per the card's own analysis — there is nothing to fix in this repo; if the re-drive on a current console build reproduces it, the defect card gets filed in objectui with the evidence (file-at-destination), and this card closes into it.dateRange"Custom…" option — either consumes this card (defect → objectui card; artifact → close as not planned).dateRangecustom picker; the passing drill-through/global-filter items in run QA run · dashboards (FULL area) · a86db175 · 2026-08-11 · 6 PASS / 2 PARTIAL / 2 FAIL #7515 are recorded on the run card itself.本评论来自分诊座位 Routine（#5474 试点），不构成认领。
Generated by Claude Code
os-zhuang commentedon Aug 11, 2026
Findings triage round, 2026-08-11 (maintainer-directed). Graded: hold — unconfirmed, automation-only, on a vendored console 138 commits behind objectui main; the card exists so the re-check is not lost. Restart: next dashboards checklist run on a fresh console pin — re-drive "Custom…" manually there; reproduce ⇒ file as a defect in objectui, else close.
Generated by Claude Code
hotlong commentedon Aug 12, 2026
Triage (findings round): promoted
finding→pm:queue, routedrepo:objectui(seam card stays here per the routing rule — there is nothing to fix in this repo; if the re-drive reproduces, the defect card is filed in objectui and this one closes onto it), type Task.Why promoted now: the card's stated blocker — "the console under test was a vendored build far behind objectui main" — was materially addressed today: #8051's console pin bump landed (123 objectui commits). The re-check this card exists to preserve is now meaningful, and it is the only way this observation ever resolves; holding it longer just ages it. Scope stays exactly the card's own four-step protocol: re-drive "Custom…" on a current build, manually as well as under automation; reproduce ⇒ file in objectui with captured evidence and close this card onto it; not reproduce ⇒ close as automation artifact with a note.
Dispatch note for the objectui seat: this is a browser-verification card ⇒
mode:cloudper the dispatch backend rules. Expected outcome is a verdict either way —premise_still_valid: false(artifact) is a fully successful delivery here, not a failure.Size/model suggestion: S verification run,
sonnet/opusper seat's judgment.Generated by Claude Code
hotlong commentedon Aug 12, 2026
Finding-grading round: closed, not planned (and
pm:queueremoved — it had been re-applied today, recreating the exactfinding+pm:queuehalf-state a triage pass deliberately dissolved on 08-11).Unconfirmed, automation-only, single sighting against a console pin now 138+ commits stale; the "so the re-check isn't lost" purpose is already served by the standing dashboards checklist items driving a custom dateRange window (
docs/qa/platform-checklist/areas/dashboards.json). If it reproduces on a current pin, file fresh in objectui with evidence.Generated by Claude Code