20.27 Blocking Partial Join

Fires on M-of-N branch completions, but blocks re-enablement of the join until ALL N branches from the current cycle complete. Prevents the next activation cycle from starting before the current cycle is fully resolved — avoiding inter-cycle interference.


Motivating Scenario

A CI/CD pipeline runs 5 test suites in parallel for each build: unit tests, integration tests, end-to-end tests, performance tests, and a security scan. Deployment is triggered when 3 of the 5 suites pass — a quality gate that balances speed against coverage. However, the deployment stage must not accept a new build batch until all 5 test suites from the current build finish. Without this blocking constraint, a slow security scan from build N could still be executing when build N+1 starts, causing test infrastructure collisions and false test attribution.

The key insight: the partial join (3-of-5) controls when deployment can proceed within a cycle. The blocking constraint controls when a new cycle can begin. These are two distinct governance concerns layered on the same join node. In high-frequency CI/CD systems where builds arrive every 2..5 minutes and security scans can take 8..12 minutes, inter-cycle isolation is not a theoretical concern — it is a daily operational reality.

Structure

Zoom and pan enabled · Concrete example: CI/CD pipeline with 3-of-5 deployment gate and cycle isolation

Key Metrics

MetricSignal
Gate fire latency (M-of-N) Time from build artifacts to 3rd passing suite — the deployment latency for this pattern
Cycle block duration Time from gate fire to AND-join completion — quantifies how long the system is blocked from accepting the next build
Suite timeout rate Fraction of cycles where at least one suite hits the timeout — key signal for infrastructure reliability
Late failure rate Fraction of cycles where suites completing after the gate report failures — validates whether M=3 is a sufficient quality threshold
NodeWhat it doesWhat it receivesWhat it produces
Build Artifacts Compiles source and produces the artifact set for this build cycle Source commit + build config Build artifacts for all 5 test suites
Unit / Integration / E2E / Perf / Security Each suite runs independently against the build artifacts and emits a pass/fail result Build artifacts + suite-specific config Pass/fail result token
3-of-5 Gate (partial join) Fires when 3 passing results arrive. Triggers deployment. Remains blocked from re-firing until all 5 suites complete (from the current cycle). Result tokens from test suites Deployment authorization for current build
Deploy Executes the deployment pipeline for the authorized build Deployment authorization + artifact reference Deployed build
Wait All Suites (AND-join) Collects completion signals from all 5 test suites. Fires when all 5 complete — releasing the blocking constraint and clearing the cycle. Completion signals from all 5 suites Cycle-complete signal

When to Use

Use when
Avoid when

Value Profile

Origin of ValueWhere it appearsHow it is captured
Future Cashflow Deployment cadence Deployment proceeds at M-of-N speed rather than waiting for the slowest suite. For a 12-minute security scan on a 3-minute build, this is a 4x improvement in deployment latency when M=3.
Governance Blocking constraint (AND-join) Cycle isolation is the primary governance mechanism. It prevents one cycle's slow branches from contaminating the next cycle's resource allocation or test attribution.
Conditional Action All 5 test suites All suites run to completion regardless of partial join firing. Suites that complete after the gate do not contribute to the deployment decision but consume full compute.
Risk Exposure AND-join (Wait All Suites) A straggler suite that never completes holds the blocking constraint open indefinitely. Next cycle cannot start. Timeouts are mandatory at each suite level.
Two-layer join semantics. 20.27 encodes two distinct firing rules on one structural join node: fire for deployment at M, unblock at N. This duality is the source of both its power and its complexity. When implementing, make both thresholds explicitly configurable — they represent independent policy decisions (quality gate vs. cycle isolation) that evolve on different timescales.

Dynamics and Failure Modes

Permanent block from a hanging suite

The security scan enters an infinite loop and never emits a completion signal. The AND-join waits indefinitely. The next build cycle cannot start. Production deployment is effectively halted. Fix: enforce a hard timeout on every test suite. After timeout, the suite emits a forced failure token. The AND-join accepts failure tokens as valid completions for unblocking purposes — only passing tokens are relevant to the 3-of-5 deployment gate.

Deployment fires before all suites report

The 3-of-5 gate fires and deployment begins. The remaining 2 suites complete during deployment and report failures. Deployment is already in progress. Fix: define whether late failures can trigger a deployment rollback. If yes, route post-gate failures to a rollback evaluation node. If no, document this accepted risk and ensure the monitoring layer can detect post-deployment failures.

Cycle boundary ambiguity under high load

Build N+1 arrives before all 5 suites from build N complete. The blocking constraint is in effect, so N+1 is queued. If N+1 also spawns 5 suites immediately (eager start), and some N suites share infrastructure with N+1 suites, test results can cross-contaminate. Fix: never start the Build Artifacts step for cycle N+1 until the Wait All Suites gate for cycle N has cleared.

Variants

VariantModificationWhen to use
Mandatory Suite Override One suite (e.g., security) is always required in the M; remaining M-1 slots are filled by first completers Some suites are non-negotiable for compliance — the partial join cannot fire without them regardless of speed
Tiered Blocking Two thresholds: M fires deployment, M+1 fires a more comprehensive staging deployment; N unblocks the cycle Multi-stage deployment requires incremental quality gates within a single build cycle
Soft Blocking with Override The blocking constraint can be manually overridden by a human operator in emergency deployment scenarios Cycle isolation is normally required but production incidents may demand overriding the block

Related Patterns

PatternRelationship
40.46 Structured Partial JoinThe non-blocking variant — fires at M-of-N with no cycle isolation constraint; simpler when inter-cycle interference is not a concern
40.44 Blocking DiscriminatorFires on the first (1-of-N) branch and blocks until all N complete — 20.27 generalized to M-of-N
40.48 Generalised AND-JoinThe full-N blocking join — use when all branches must complete, not just M
20.22 Human in the LoopThe blocking constraint can be replaced with a human approval gate when cycle closure requires human sign-off