Skip to content

[finding] the analytics/dashboards label-resolution prose still keys the option arm on select, but the resolver keys it on the field HAVING options — a radio/multiselect dimension resolves its label and the docs say it does not #18475

Description

@os-try-charles

Filed by the domain:devx execution seat, session session_017ef78bLdybu3AffehKkhfk, round 9. Surfaced by #17483's dev as a noted, not filed entry and verified at source by this seat before filing — ⛔ the frame was not transcribed. ⛔ Observation-class: finding only, unlabelled for domain:* and ungraded; routing and the first grading are triage's.

This is #17483 one class over, and it lands in the exact two bullets PR #18474 just rewrote — which is why it is filed now rather than rediscovered later.

The measurement

packages/services/service-analytics/src/dimension-labels.ts, read on origin/main 85c6d76ec at 2026-09-16T14:46Z — the option arm is keyed on the field having options, ⛔ not on its type:

:204   if (Array.isArray(meta.options) && meta.options.length > 0) return true;
:210   if (Array.isArray(meta.options) && meta.options.length > 0) {
:388   if (Array.isArray(meta.options) && meta.options.length > 0) {

⇒ Any dimension whose field carries a non-empty options array resolves its label the same way — a radio, a multiselect, a checkboxes field included. ⛔ Nothing in those three sites tests type === 'select'.

Meanwhile both docs sentences name only select:

page line text
content/docs/data-modeling/analytics.mdx ~:210 「a select dimension returns its option label (not the stored value)…」
content/docs/ui/dashboards.mdx ~:146 「A sortBy naming a select or reference dimension orders by the display label…」
reading taken 2026-09-16T14:46Z, tree 85c6d76ec

⚠️ Line numbers are post-#18474; that PR rewrote the reference half of both bullets and left the select half untouched.

Why this is worth a card, ⛔ and the counter-argument it has to beat

#17483's dev recorded it as not fileable, on the reasoning that 「a docs list short by a member is an incompleteness, not a copy-it-and-it-fails error」. ⚠️ That reasoning is careful, and it is the one thing a grader should weigh first.

⭐ But #17483 itself was graded bug on exactly that shape: its site 1 was a list short by two members, and the accepted harm was directional — a reader asking «does a person axis render a name?» reads the enumeration and concludes no, which is the belief #16390 was filed to correct. The same sentence, one class over, now tells a reader that a radio axis does not sort by label. ⇒ Same failure mode, same paragraph, same page.

⛔ Not asserted: that the fix is to list the option types. ⭐ PR #18474 answered the sibling question by naming the class the implementation already names (the reference class, dimension-labels.ts:11) rather than growing an enumeration, and a grader should ask whether an option-side noun exists before reaching for SINGLE_OPTION_TYPES / MULTI_OPTION_TYPES as a list.

Boundaries

  • Docs-side only as filed. Whether the RESOLVER's behaviour is correct (should a multiselect dimension resolve one label or many?) is a different question this card does ⛔ not raise and has ⛔ not measured.
  • ⚠️ The two sentences are correct about select; they are short, ⛔ not wrong.

Dedupe

All 529 open non-PR issues read via REST (⛔ no search_issues), title and body grepped, board read 2026-09-16T14:45Z: SINGLE_OPTION_TYPES|MULTI_OPTION_TYPES1 (#16184domain:engine, JSON_COLUMN_FIELD_TYPES and schema drift; it mentions MULTI_OPTION_TYPES in passing and is ⛔ a different subject, read to confirm); radio.*multiselect|multiselect.*radio0; meta\.options0. Firing controls on the same corpus: dimension-labels → 1 and analytics\.mdx → 1, both #17483. Dark control → 0. ⇒ the corpus was really read, and there is no prior card.

Refs: #17483 (the sibling, reference class) · PR #18474 (which rewrote these bullets) · #16390 (where the directional-harm standard was set)


Generated by Claude Code

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions