docs(changelog): flaky tests filterable uploads history

[samgutentag]

What shipped

The Flaky Tests uploads page now shows a filterable, paginated history of every CI test upload: a stacked Pass/Fail/Other daily bar chart (click a range to filter), a multi-value filter bar (upload status, job conclusion, PR number, SHA, branch, author), a URL-persisted column customizer, and a polling refresh button with a new-uploads count badge.

Source

• Eng PR: trunk-io/trunk2#3670 (merged 2026-04-28)
• Linear: TRUNK-18133 (no absorbed duplicates)
• Date basis: trunk2#3670 mergedAt = 2026-04-28

Wired into all 4 sites

• changelog/2026-04-28-flaky-tests-filterable-uploads-history.mdx
• docs.json (Changelog tab, 2026 group)
• changelog/index.mdx (April 2026)
• flaky-tests/changelog.mdx (new April 2026 section)

Note

Feature is gated behind LaunchDarkly flag enableFilteredUploadsPage. Ticket is tagged [feature not live] — this PR is expected to verify as pending until the flag is on in prod.

🤖 Generated with Claude Code

[mintlify]

Preview deployment for your docs. Learn more about Mintlify Previews.

Project	Status	Preview	Updated (UTC)
trunk	🟢 Ready	View Preview	May 29, 2026, 5:51 AM

💡 Tip: Enable Workflows to automatically generate PRs for you.

[samgutentag]

Verification status (2026-05-29): staged

On in staging only. Re-run after prod rollout.

• Flag state: read directly from LaunchDarkly (production: OFF; test: ON_100)
• Eng PR: trunk-io/trunk2#3670 (merged 2026-04-28, intact on main)
• Flag: enableFilteredUploadsPage (project frontend-web-2)
• Signals: LaunchDarkly get-flag (primary). production on=false (off variation served). test (Staging) on=true, fallthrough serves the enabling true variation (index 0) at 100%.

Hold publishing until enableFilteredUploadsPage is enabled in production. Re-run /verify-docs-pr 156 after the prod rollout. (Prior verdict was pending from the Slack/legacy heuristic, which could not see staging state; the direct LaunchDarkly read corrects it to staged.)

[samgutentag]

Code verification (2026-05-28): 6 confirmed / 0 contradicted / 0 ambiguous / 0 unverifiable

(One claim, "each filter accepts multiple values", was contradicted on first pass and corrected in commit 3e5518e before this verdict. The table below reflects the corrected entry.)

Claim	Verdict	Source
Filterable, paginated uploads history page gated behind enableFilteredUploadsPage	confirmed	flaky-tests-feature-flags-context.tsx
Stacked daily chart with Pass / Fail / Other bins, click range to filter	confirmed	trunk2#3670 CHART_SERIES + SelectableBarChart
Filters: upload status, job conclusion, PR, SHA, branch, author	confirmed	trunk2#3670 MultiFilter filterKeys
Five of six filters accept multiple values (status, PR, SHA, branch, author); job conclusion is single-value	confirmed	trunk2#3670 products-parser.ts
Column customizer with state persisted in URL search params	confirmed	trunk2#3670 UploadsColumnCustomizer / uploadColumns param
Polling refresh button with new-uploads count badge	confirmed	trunk2#3670 refresh-button.tsx

The original draft claimed "each filter accepts multiple values." Source shows uploadJobConclusion parses as a single string literal, not an array, so the job-conclusion filter takes one value. Fixed in the entry: the multi-value claim now names only the five array-backed filters.

---

Source #1 — Chart bins are Pass / Fail / Other (confirmed)

File: trunk-io/trunk2#3670, filtered uploads client (new file)

const CHART_SERIES: BarSeries[] = [
  { key: "passCount", color: "#22c55e", label: "Pass" },
  { key: "failCount", color: "#ef4444", label: "Fail" },
  { key: "otherCount", color: "#94a3b8", label: "Skipped, Pending, Dry Run" },
];

Reasoning: Three series, exactly Pass / Fail / Other. The "Other" bin's source label is "Skipped, Pending, Dry Run"; the changelog's "Other" is a fair umbrella for that. The uploadChartData GraphQL query returns { date, passCount, failCount, otherCount }, and the chart uses the existing SelectableBarChart with drag-to-select date-range filtering, confirming "click a range to filter".

Source #2 — Six filter keys, five multi-value (confirmed, after fix)

File: trunk-io/trunk2#3670, products-parser.ts and the uploads page MultiFilter

// MultiFilter filterKeys on the uploads page
filterKeys={[ "uploadPr", "uploadSha", "uploadBranch", "uploadAuthor",
              "uploadJobConclusion", "uploadStatus" ] as const}

// nuqs parsers
uploadPr: parseAsArrayOf(parseAsString),
uploadSha: parseAsArrayOf(parseAsString),
uploadBranch: parseAsArrayOf(parseAsString),
uploadAuthor: parseAsArrayOf(parseAsString),
uploadJobConclusion: parseAsStringLiteral(JobConclusionValues),
uploadStatus: parseAsArrayOf(parseAsStringLiteral(BundleUploadStatusValues)),

Reasoning: All six filters the changelog names exist. parseAsArrayOf = multiple values; parseAsStringLiteral (no array wrapper) = single value. So uploadStatus, uploadPr, uploadSha, uploadBranch, uploadAuthor are multi-value, but uploadJobConclusion is single-value. The original "each filter accepts multiple values" was too broad; corrected to name the five array-backed filters.

Source #3 — URL-persisted column customizer and polling refresh button (confirmed)

File: trunk-io/trunk2#3670, datatable components

- column-customizer.tsx — popover button for toggling column visibility (UploadsColumnCustomizer); state in uploadColumns URL param.
- refresh-button.tsx — Button that shows a badge count of new items and triggers a manual refresh.

// polling for new uploads since last refresh
const { data: pollingData } = useQuery(/* ... */, { pollInterval: 20_000 });

Reasoning: Column visibility is encoded in the uploadColumns URL search param (shareable/bookmarkable, per the eng design notes). The refresh button shows a badge count of new items and triggers a manual refetch; a separate useQuery with pollInterval: 20_000 polls every 20s for new uploads since the last refresh. Both the "polling refresh button" and "count badge for new uploads" claims hold.

[samgutentag]

Verification status (May 30, 2026): staged

On in staging only. Re-run after prod rollout.

• Flag state: read directly from LaunchDarkly (production: OFF; test: ON_100). enableFilteredUploadsPage in frontend-web-2: prod on=false, test on=true fallthrough variation 0 (true) = ON_100. No targeting rules. Unchanged from yesterday.
• Eng PR: trunk-io/trunk2#3670 (merged 2026-04-28, intact on main).
• Flag: enableFilteredUploadsPage (project frontend-web-2, maintainer: Tyler).
• Signals: LaunchDarkly get-flag called directly this sweep. Prod OFF, staging ON_100. No change since last sweep.

Hold publishing until enableFilteredUploadsPage is enabled in production. Re-run after the prod rollout.

---

Generated by Claude Code

[samgutentag]

Verification status (May 31, 2026): staged

On in staging only. Re-run after prod rollout.

• Flag state: read directly from LaunchDarkly (production: OFF; test: ON_100). enableFilteredUploadsPage in frontend-web-2: prod on=false, test on=true fallthrough variation 0 (true) = ON_100. Confirmed same state as May 30.
• Eng PR: trunk-io/trunk2#3670 (merged 2026-04-28, intact on main)
• Flag: enableFilteredUploadsPage (project frontend-web-2, maintainer: Tyler)
• Signals: LaunchDarkly get-flag called directly this sweep. Prod OFF, staging ON_100. No change since last sweep.

Hold publishing until enableFilteredUploadsPage is enabled in production. Re-run after the prod rollout.

---

Generated by Claude Code

[samgutentag]

Verification status (June 1, 2026): staged

On in staging only. Re-run after prod rollout.

• Flag state: read directly from LaunchDarkly (production: OFF; test/staging: ON_100). For enableFilteredUploadsPage in frontend-web-2, enabling variation is index 0 (value=true). Production: on=false (OFF). Staging (test): on=true, fallthrough variation 0 = 100% enabled (ON_100). No targeting rules either env. Same state as prior sweeps.
• Eng PR: trunk-io/trunk2#3670 (merged 2026-04-28, intact on main).
• Flag: enableFilteredUploadsPage (project frontend-web-2, maintainer Tyler).
• Signals: LaunchDarkly is the primary signal. Prod flag off, so the filtered uploads page is not yet visible to customers.

Next: keep in draft. Re-run after the flag flips on in production. PR is conflicting on shared changelog nav files; conflicts handled separately. Unchanged from prior sweep.

---

Generated by Claude Code