Document batching, PFD, and parallel-queue interactions

[samgutentag]

Summary

• Add a new "How batching interacts with parallel queues and PFD" section to merge-queue/optimizations/batching.mdx covering: batching as a lane, PR batch eligibility, ALL-keyword non-serialization, transitive dependents, bisection splits in half, PFD's downstream-PR delay, optimistic-off batch-removal restarts, and MQ-only failures not feeding flakiness signals today.
• Cross-link from pending-failure-depth.mdx (Next Steps) and parallel-queues/index.mdx (Related) into the new section.
• Link to the webhooks reference for the event-side view of pending-failure batch events.

Why

Sourced from customer feedback mining (cluster batching-and-pending-failure-depth, verdict partial, 7 pairs across 4 customers). Existing pages explain batching, PFD, and bisection individually; customers hit confusion when these interact (e.g., the PFD-delay-when-downstream-still-testing case, ALL-keyword not serializing parallel PRs, optimistic-off causing batch-removal restarts). This PR addresses the cross-interaction framing gap the verifier called out, without re-documenting the individual features.

Items flagged for review

• PFD downstream-PR delay example — verify wording matches eng intent. The example states that a newly-arrived PR-C with overlapping targets extends the wait before PR-A is kicked. Confirm "shares impacted targets" is the right gate (vs. all successors regardless of target overlap).
• ALL keyword serialization claim — confirm the wording on concurrency interaction. The section says downstream PRs without shared targets can test in parallel behind an ALL-impacting PR "up to your testing concurrency." Verify this matches the parallel-mode behavior exactly.
• "Open to adding number of conclusions alongside depth" — the source thread mentions Phil being open to this. The doc reframes it as "active area of design — share your use case with support" to avoid promising a roadmap item. Confirm the soft framing is acceptable.
• Bisection concurrency framing — claim is that "setting it equal to your batch size is more than you need" because bisection is logarithmic. Worth a sanity check against current bisection implementation.
• Optimistic-off restart wording — the doc attributes batch-removal restarts to optimistic merging being disabled. Source confirms this for one case; verify it's the general rule.
• MQ-only failures and flakiness — claim is that MQ-only failures and bisection runs aren't fed into Flaky Tests "today." Verify this is still accurate and that the soft "yet"-style framing is right.
• Cross-link to webhooks anchor — currently links to ../webhooks without anchor since PR Rewrite webhooks reference with event lifecycle and v1/v2 schema notes #52 (webhook lifecycle reference) is not yet merged. Once Rewrite webhooks reference with event lifecycle and v1/v2 schema notes #52 lands, update to ../webhooks#pending-failure-batch (or whatever the final anchor is).

Customer signal

• Cluster: batching-and-pending-failure-depth (verdict: partial, 7 pairs / 4 customers)
• Channels: trunk-faire, trunk-appliedintuition
• Source threads:
  • PFD downstream-PR delay
  • bisection splits in half
  • batch is a lane
  • ALL keyword non-serialization
  • transitive-dependent batching
  • MQ-failures vs flakiness
  • optimistic-off batch-removal restart

[mintlify]

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

Project	Status	Preview	Updated (UTC)
trunk	🟢 Ready	View Preview	May 20, 2026, 11:52 PM

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