Skip to content

[TRUNK-17579] Clarify Testing Concurrency and Bisection Concurrency relationship #437

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
samgutentag wants to merge 2 commits into
base: main
Choose a base branch
from
Open

[TRUNK-17579] Clarify Testing Concurrency and Bisection Concurrency relationship #437

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
53d776f
Clarify Testing Concurrency and Bisection Concurrency relationship
samgutentag Feb 17, 2026
d550c6a
Refine bisection concurrency docs with cross-references and notificat…
samgutentag Feb 18, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
16 changes: 14 additions & 2 deletions merge-queue/administration/advanced-settings.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -15,6 +15,10 @@ All of the following settings are specific to individual Merge Queues and can be
Note that you must be an Organization admin to adjust any of these settings.
{% endhint %}

{% hint style="info" %}
All queue settings can also be managed programmatically using the [Queue management API endpoints](../reference/merge.md#queue-management-endpoints). This is useful for automating queue configuration across multiple repositories or integrating with infrastructure-as-code workflows.
{% endhint %}

***

## Merge Queue state
Expand Down Expand Up @@ -183,6 +187,10 @@ The merge method is configured per repository, so different repositories in your

Configure how many PRs may be tested in parallel. A larger number may increase throughput since more PRs are tested in parallel, but at the expense of CI since more jobs are running in parallel. When the queue is at capacity, PRs will still be submitted to it, but they will not begin testing until a PR leaves the queue.

{% hint style="info" %}
When [Batching](advanced-settings.md#batching) is enabled, Testing Concurrency applies only to the main queue. Bisection tests during batch failure isolation use a separate [Bisection Testing Concurrency](advanced-settings.md#bisection-testing-concurrency) setting.
{% endhint %}

{% hint style="info" %}
If your testing workload contains some flaky tests, a deeper queue (i.e., a higher concurrency) may struggle. Running Merge in Parallel mode can help with this, as it will reduce the average depth of your merge queue since all PRs won't be queued directly behind each other.
{% endhint %}
Expand Down Expand Up @@ -299,12 +307,16 @@ Whether or not GitHub slash commands like `/trunk merge` are enabled for this me

### Bisection Testing Concurrency

Configure how many PRs can be tested simultaneously during batch failure isolation (bisection). This setting is independent from the main Testing Concurrency and only applies when batches fail and need to be split to identify the failing PR.
Configure how many PRs can be tested simultaneously during batch failure isolation (bisection). This setting is independent from the main [Testing Concurrency](advanced-settings.md#testing-concurrency) and only applies when batches fail and need to be split to identify the failing PR.

**Default:** Same as Testing Concurrency (automatically mirrors your main concurrency setting)
**Default:** When not explicitly configured, bisection uses the same concurrency as your main Testing Concurrency setting. We recommend setting this to a higher value for faster failure isolation.

**Recommended:** Set 2-5x higher than your main Testing Concurrency for faster failure isolation

{% hint style="info" %}
Changes to Bisection Testing Concurrency are reported in Slack notifications and GitHub PR comments when those integrations are enabled.
{% endhint %}

#### How to Configure

1. Navigate to **Settings** > **Repositories** > your repository > **Merge Queue** > **Batching**
Expand Down
4 changes: 2 additions & 2 deletions merge-queue/optimizations/batching.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -34,13 +34,13 @@ A good place to start is with the defaults, Maximum wait time set to 5 (minutes)

### Bisection Testing Concurrency

When a batch fails, Trunk automatically splits it apart (bisects) to identify which PR caused the failure. You can configure a separate, higher concurrency limit specifically for these bisection tests to isolate failures faster without impacting your main queue.
When a batch fails, Trunk automatically splits it apart (bisects) to identify which PR caused the failure. You can configure a separate, higher concurrency limit specifically for these bisection tests to isolate failures faster without impacting your main queue. This setting is independent from the main [Testing Concurrency](../administration/advanced-settings.md#testing-concurrency), which applies only to the main queue when batching is enabled.

<figure><img src="../../.gitbook/assets/1768426960-batching-settings.avif" alt=""><figcaption></figcaption></figure>

#### Why Separate Bisection Concurrency?

By default, bisection tests use the same concurrency limit as your main queue. This means:
By default, bisection tests use the same concurrency limit as your main queue when bisection concurrency is not explicitly configured. This means:

* Bisection can slow down other PRs waiting to merge
* Developers wait longer to learn which PR broke the batch
Expand Down
Loading