feat: clear parallel constraints and limiter during test registration

[thomhurst]

Closes #6892

Summary

Adds two methods to TestRegisteredContext so an ITestRegisteredEventReceiver can remove the parallelization of a test:

• ClearParallelConstraints() removes every constraint on the test, for example those added by [NotInParallel] and [ParallelGroup].
• ClearParallelLimiter() removes the limiter, whether [ParallelLimiter<T>] or SetParallelLimiter set it. It also resets the explicit-attribute precedence, so a limiter set after the clear still applies.

public ValueTask OnTestRegistered(TestRegisteredContext context)
{
    if (IsNestedRun)
    {
        context.ClearParallelConstraints();
        context.ClearParallelLimiter();
    }

    return default;
}

Constraint attributes add their constraints during discovery, which runs before any registration receiver. [ParallelLimiter<T>] sets its limiter during registration with Order => 0, so a receiver that clears it needs a higher Order. The XML docs say this.

The scheduler groups tests after registration from the live TestContext state, so no engine change is needed. Both metadata modes share this path.

Tests

• tests/TUnit.TestProject/Bugs/6892: two tests share a [NotInParallel] key and a limit of 1, and they finish only if they run at the same time (TCS rendezvous, same pattern as Running TestsCases produced by Arguments not in parallel with each other but parallel with any other test #5700). They fail without the clear. A second test checks that a limiter set after the clear is applied.
• tests/TUnit.Engine.Tests/ClearParallelizationTests: passes in source-generated and reflection modes. AOT mode runs only in CI.
• tests/TUnit.PublicAPI snapshots updated for the two new public methods.

Summary by CodeRabbit

• New Features
  • Added the ability to clear previously set parallel constraints and parallel limits for registered tests. These settings can still be applied again afterward.

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-09-27T10:27:46.009865Z	05613ff	PR opened

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

[coderabbitai]

Navigate logical layers of code changes, visualize relationships, and explore their blast radius.

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Advanced

Run ID: 125e5784-3169-454f-89e8-c695a6cd0a43

📥 Commits

Reviewing files that changed from the base of the PR and between 0ec4543 and 05613ff.

📒 Files selected for processing (8)

• src/TUnit.Core/Contexts/TestRegisteredContext.cs
• src/TUnit.Core/TestContext.Parallelization.cs
• tests/TUnit.Engine.Tests/ClearParallelizationTests.cs
• tests/TUnit.PublicAPI/Tests.Core_Library_Has_No_API_Changes.DotNet10_0.verified.txt
• tests/TUnit.PublicAPI/Tests.Core_Library_Has_No_API_Changes.DotNet8_0.verified.txt
• tests/TUnit.PublicAPI/Tests.Core_Library_Has_No_API_Changes.DotNet9_0.verified.txt
• tests/TUnit.PublicAPI/Tests.Core_Library_Has_No_API_Changes.Net4_7.verified.txt
• tests/TUnit.TestProject/Bugs/6892/ClearParallelizationTests.cs

Included review availability: This review used your included allowance. Your plan provides up to 8 included reviews per hour; 6 remain after this review.

---

📝 Walkthrough

Walkthrough

TestRegisteredContext now provides methods to clear parallel constraints and the parallel limiter during registration. Regression tests cover cleared parallelization state and verify that a later receiver can set a limiter.

Changes

Parallelization clearing

Layer / File(s)	Summary
Add parallelization clearing APIs src/TUnit.Core/Contexts/TestRegisteredContext.cs, src/TUnit.Core/TestContext.Parallelization.cs, tests/TUnit.PublicAPI/Tests.Core_Library_Has_No_API_Changes.*.verified.txt	TestRegisteredContext adds methods to clear the parallel limiter and constraints. TestContext clears stored constraints when the collection exists. Public API baselines list both methods.
Verify clearing and later limiter registration tests/TUnit.TestProject/Bugs/6892/ClearParallelizationTests.cs, tests/TUnit.Engine.Tests/ClearParallelizationTests.cs	Regression tests check that clearing removes constraints and the limiter, and that a later receiver can set a limiter. Engine tests assert the filtered cases complete with the expected passing counts.

Priority: ⬇️ Low

Estimated code review effort: 2 (Simple) | ~12 minutes

Change: Feature

Sequence Diagram(s)

sequenceDiagram
  participant TestRegistrationPipeline
  participant ClearingReceiver
  participant TestRegisteredContext
  participant TestContext
  participant LaterReceiver
  TestRegistrationPipeline->>ClearingReceiver: invoke registration receiver
  ClearingReceiver->>TestRegisteredContext: ClearParallelConstraints()
  TestRegisteredContext->>TestContext: clear stored constraints
  ClearingReceiver->>TestRegisteredContext: ClearParallelLimiter()
  TestRegistrationPipeline->>LaterReceiver: invoke later registration receiver
  LaterReceiver->>TestRegisteredContext: set parallel limiter

Loading

Merge Risk: ⚪ Minimal · up to 05613

The registration-time clearing behavior has no identified issue requiring resolution before merge.

Security Architecture Review

Security architecture risk: 🔵 Low · up to 05613

The change can make selected tests run concurrently when they previously could not. The reviewed path gives that choice to code registering its own tests, not to an external caller, and no security finding was established.

Retained concerns
No architecture-level concerns identified.

Security review details

Security Blast Radius

• inferred — The evidenced effect is scheduling of tests whose receivers clear their metadata: those tests can enter an unconstrained group or execute without a limiter lock. No tenant, service, credential, or data-store authority change was evidenced.

Trust Boundaries and Controls

• observed — The engine supplies the context to registration receivers, and the runner applies the limiter remaining on the test context. Clearing that value deliberately skips limiter acquisition; it is not a bypass of a separate enforcement value in the inspected runner path.

Resilience and Maintainability Implications

• observed — A registration receiver failure propagates. Dynamic tests on the inspected path are enqueued only after registration succeeds, limiting exposure to partially registered scheduling state there.

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 21.43% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 14 functions across 4 files. (4 skipped: …	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly and concisely describes the main change: adding registration-time APIs to clear parallel constraints and the limiter.
Linked Issues check	✅ Passed	Issue #6892 requires registration-time removal of parallel constraints and the parallel limiter. The PR adds TestRegisteredContext.ClearParallelConstraints() and ClearParallelLimiter(). The limite…
Out of Scope Changes check	✅ Passed	The changes stay within issue #6892. The added implementation, regression tests, and public API baselines directly support the new registration-time clearing APIs. No unrelated production behavior or …

Full details: Docstring Coverage

Explanation

Docstring coverage is 21.43% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 14 functions across 4 files. (4 skipped: 4 unsupported.)

• Fix all pre-merge checks with AI

✨ Finishing Touches 💡 2

📝 Generate docstrings 💡

• Commit to this branch
• Create a new PR

🧪 Generate unit tests (beta)

• Commit to this branch
• Create a new PR

🛠️ Fix failing CI checks 💡

• Commit to this branch
• Create a new PR

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{A rabbit clears the limits in flight
And frees each test from constraints tight
Two tests meet and both pass through
A later limiter takes its cue
I twitch my nose and thump good cheer!}

_{Comment @coderabbitai help to get the list of available commands.}

[greptile-apps]

Confidence Score: 5/5

[Medium risk] Adds methods to clear test parallelization constraints and limiters.

The PR appears safe to merge; no actionable issue was identified.

Summary

Adds registration-time APIs to clear a test’s parallel constraints and limiter, including the explicit limiter precedence state.

• Adds regression coverage for concurrent execution and setting a limiter after clearing one.
• Updates public API snapshots across supported targets.

Diagram

%%{init: {'theme': 'neutral'}}%%
flowchart LR
    A[Discovery adds constraints] --> B[Registration receivers set or clear parallel state]
    B --> C[Scheduler groups tests using current constraints]
    C --> D[Runner reads current limiter before execution]

Loading

_{Reviews (1) · Last reviewed commit: "feat: let registration receivers clear p..."}

[github-actions]

Code Review

Reviewed the two new registration-time APIs on TestRegisteredContext (ClearParallelConstraints(), ClearParallelLimiter()) and their supporting change to TestContext.Parallelization.cs.

Correctness

• The phase ordering the feature depends on holds up: [NotInParallel]/[ParallelGroup] add constraints during discovery, [ParallelLimiter<T>] sets the limiter during registration at Order => 0, and the scheduler reads live TestContext state after all registration receivers run — so a receiver with a higher Order (e.g. the sample's Order => 100) correctly sees and clears prior state before scheduling groups tests.
• ClearParallelLimiter() correctly resets _explicitParallelLimiter in addition to TestContext.ParallelLimiter, so a limiter set by a later receiver via SetParallelLimiter isn't silently overridden by the old explicit-attribute precedence logic. The added ClearParallelLimiterThenSetTests test exercises exactly this path.
• ClearParallelConstraints() null-guards _parallelConstraints before clearing, consistent with the existing lazy-init (??= []) pattern in AddConstraint.
• Both mutated fields are internal, backing simple in-process state set up before the test executes; no cross-thread mutation of the same context is introduced by this change, so no additional synchronization is needed.

Metadata parity

• No changes were needed in TUnit.Core.SourceGenerator, since the scheduler groups tests from live TestContext state after registration, not from generator-produced metadata. Confirmed both source-generated and reflection engine test modes are covered by ClearParallelizationTests.

Tests & docs

• The regression test in tests/TUnit.TestProject/Bugs/6892 uses a TCS rendezvous (mirroring the existing Repro5700 pattern) to prove the two tests genuinely run concurrently rather than just not throwing — a meaningful assertion, not just "it didn't crash."
• Public API snapshots are updated consistently across all four TFMs.
• XML doc comments clearly call out the Order precedence requirement, which is the one non-obvious gotcha in this API.

No correctness, thread-safety, or convention issues found. This is a small, well-scoped, well-tested addition — nothing to change.

🤖 Generated with Claude Code