docs(changelog): branch scope for the pass-on-retry monitor

[samgutentag]

What shipped

The pass-on-retry monitor now supports a configurable branch scope. Teams can restrict pass-on-retry detection to specific branches (e.g. main, release/*) to cut noise from automatic PR-branch retries. Default remains all branches (*); branch scope uses the failure rate monitor's glob syntax and accepts up to 10 patterns.

Source

• Eng PRs: trunk-io/trunk2#3843 (backend), trunk-io/trunk2#3909 (UI)
• Linear: TRUNK-18224 (no absorbed duplicates)
• Date basis: 2026-05-06 = latest mergedAt of the two source PRs (UI PR #3909, merged 2026-05-06).

Wired into all 4 sites

• changelog/2026-05-06-flaky-tests-pass-on-retry-branch-scope.mdx (entry)
• docs.json (Changelog tab, 2026 group)
• changelog/index.mdx (May 2026 section)
• flaky-tests/changelog.mdx (product index, May 2026 section)

Docs link target: https://docs.trunk.io/flaky-tests/detection/pass-on-retry-monitor (exists; already documents branch scope).

🤖 Generated with Claude Code

[samgutentag]

Verification status (2026-05-28): live

Verified: customers can use this. Ready to publish.

• Eng PR: trunk-io/trunk2#3843 (backend), trunk-io/trunk2#3909 (UI)
• Flag: none (no LaunchDarkly flag in either PR body or diff; the change adds a branchFilter arg to the existing POR CRUD/detect/resolve flow, UI defaults to all branches *)
• Signals: both eng PRs MERGED (2026-05-06); both merge commits confirmed present on main (compare status behind, merge intact); no feature-flag gating found, so no rollout ramp required

No further action needed. Take the PR out of draft and publish when ready.

[mintlify]

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

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

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

[samgutentag]

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

Claim	Verdict	Source
Default branch scope is all branches (*)	confirmed	pass-on-retry-monitors-section.tsx
Branch scope accepts up to 10 patterns	confirmed	monitor-branch-scope-section.tsx
Same glob syntax as the failure rate monitor (shared component)	confirmed	monitor-branch-scope-section.tsx

All three factual claims in the entry match source. No corrections needed.

---

Source #1 — Default branch scope is all branches (`*`) (confirmed)

File: trunk-io/trunk2 PR #3909, pass-on-retry-monitors-section.tsx

const [branches, setBranches] = useState<string[]>(["*"]);
// ...
return monitor.branches.length > 0 ? monitor.branches : ["*"];

Reasoning: The pass-on-retry monitor config UI initializes branches to ["*"] and falls back to ["*"] when no branches are set. The summary formatter renders ["*"] (or empty) as "all branches". This confirms the entry's "By default the monitor still evaluates every branch (*)". The UI PR #3909 body also states it "defaults to all branches (*)".

Source #2 — Branch scope accepts up to 10 patterns (confirmed)

File: trunk-io/trunk2 PR #3909, monitor-branch-scope-section.tsx

export function BranchScopeSection({
  // ...
  max = 10,
  // ...
}) { /* ... */ }
// chip input rendered with max={10}; helper text: "...to 10 patterns."

Reasoning: The shared BranchScopeSection component defaults max to 10 and passes max={10} to the pattern chip input, with helper copy capping entries "to 10 patterns". This confirms the entry's "accepts up to 10 patterns".

Source #3 — Same glob syntax as the failure rate monitor (confirmed)

File: trunk-io/trunk2 PR #3909, monitor-branch-scope-section.tsx

import { BranchScopeSection } from "./monitor-branch-scope-section";
// imported by pass-on-retry-monitors-section.tsx, failure-count-monitors-section.tsx,
// and threshold-monitors-section.tsx (failure rate)

Reasoning: PR #3909 extracts the branch scope UI into one reusable BranchScopeSection, "previously duplicated across failure rate & failure count monitor components" (PR body). The same component now backs the pass-on-retry, failure count, and threshold/failure-rate monitors, so they share identical pattern-entry and glob semantics. Backend pattern handling (branchPatternsToRegexes, MAX_PATTERN_LENGTH = 256) is also shared. This confirms the entry's "uses the same glob syntax as the failure rate monitor".