The BE already supports N8N_CONCURRENCY_EVALUATION_LIMIT as an admin cap on how many evaluation test cases run concurrently (clamp lives in packages/cli/src/evaluation.ee/test-runner/test-runner.service.ee.ts:runTest). The eval results page slider was hard-coded at 1–10, so admins lowering the cap couldn't tell from the UI, and users could pick a value the BE would silently clamp.
This surfaces the limit on the FE and binds it to the slider:
@n8n/api-types — adds evaluationConcurrencyLimit: number to FrontendSettings.
cli/services/frontend.service.ts — populates it from globalConfig.executions.concurrency.evaluationLimit.
editor-ui/parallelEval.store.ts — exposes a maxConcurrency computed that mirrors the BE clamp: min(10, limit) when limit > 0, else 10 (BE convention: <= 0 means unlimited). The setter clamps writes; the getter clamps reads without mutating storage so a previously-stored preference returns naturally if the admin later raises the cap.
editor-ui/views/EvaluationsView.vue — binds :max on the slider to the dynamic ceiling instead of the literal 10.
How to test
Default (no env var): open an eval results page with the parallel-eval feature flag on. Slider's max stop is 10.
Capped: set N8N_CONCURRENCY_EVALUATION_LIMIT=4, restart the BE, reload. Slider max is now 4. Dragging past it clamps at 4. A stored preference of 8 from a prior session displays as 4.
Unlimited: set N8N_CONCURRENCY_EVALUATION_LIMIT=-1 (or 0). Slider max returns to 10.
Raise back: set the cap to 2, then later to 8. A previously-stored preference of 7 re-appears once the cap allows it (storage was preserved, not overwritten).
Unit coverage in parallelEval.store.test.ts exercises each case (unlimited, lower-than-10, higher-than-10, zero, setter clamp, cross-call recap on cap-lower, effectiveConcurrency parity).
Related Linear tickets, Github issues, and Community forum posts
Summary
The BE already supports
N8N_CONCURRENCY_EVALUATION_LIMITas an admin cap on how many evaluation test cases run concurrently (clamp lives inpackages/cli/src/evaluation.ee/test-runner/test-runner.service.ee.ts:runTest). The eval results page slider was hard-coded at 1–10, so admins lowering the cap couldn't tell from the UI, and users could pick a value the BE would silently clamp.This surfaces the limit on the FE and binds it to the slider:
@n8n/api-types— addsevaluationConcurrencyLimit: numbertoFrontendSettings.cli/services/frontend.service.ts— populates it fromglobalConfig.executions.concurrency.evaluationLimit.editor-ui/parallelEval.store.ts— exposes amaxConcurrencycomputed that mirrors the BE clamp:min(10, limit)whenlimit > 0, else10(BE convention:<= 0means unlimited). The setter clamps writes; the getter clamps reads without mutating storage so a previously-stored preference returns naturally if the admin later raises the cap.editor-ui/views/EvaluationsView.vue— binds:maxon the slider to the dynamic ceiling instead of the literal10.How to test
10.N8N_CONCURRENCY_EVALUATION_LIMIT=4, restart the BE, reload. Slider max is now4. Dragging past it clamps at4. A stored preference of8from a prior session displays as4.N8N_CONCURRENCY_EVALUATION_LIMIT=-1(or0). Slider max returns to10.2, then later to8. A previously-stored preference of7re-appears once the cap allows it (storage was preserved, not overwritten).Unit coverage in
parallelEval.store.test.tsexercises each case (unlimited, lower-than-10, higher-than-10, zero, setter clamp, cross-call recap on cap-lower,effectiveConcurrencyparity).Related Linear tickets, Github issues, and Community forum posts
Follow-up to https://linear.app/n8n/issue/TRUST-65 (parallel eval execution), which added the
N8N_CONCURRENCY_EVALUATION_LIMITenv var on the BE.Review / Merge checklist
Backport to Beta,Backport to Stable, orBackport to v1(if the PR is an urgent fix that needs to be backported)🤖 PR Summary generated by AI