Skip to content

feat: parallel rule execution with Tokio semaphore#34

Open
evg4b wants to merge 1 commit into
masterfrom
feature/parallel-rule-execution
Open

feat: parallel rule execution with Tokio semaphore#34
evg4b wants to merge 1 commit into
masterfrom
feature/parallel-rule-execution

Conversation

@evg4b
Copy link
Copy Markdown
Owner

@evg4b evg4b commented Apr 13, 2026

Summary

  • Add ExecutionMode::{Sync, Async} enum and a Rule::execution_mode() trait method (default: Sync) so each rule type declares how it should be scheduled
  • Five dynamic rules override to Async: exec, shell, write-file, copy-files, delete-files; all validation rules remain Sync
  • Rewrite HandleCommand::exec to run both groups in parallel using std::thread::scope + tokio::sync::Semaphore (max 10 concurrent async rules via Handle::block_on)

Execution model

Phase 1 — Prepare (sequential, &mut ctx)
  • call extend() and evaluate `when` conditions for every rule

Phase 2 — Execute (parallel)
  ┌─────────────────────────────────┐  ┌──────────────────────────────────────┐
  │  Sync thread                    │  │  Async threads (one per async rule)  │
  │  branch-name-*, message-*,      │  │  exec / shell / write-file /         │
  │  suppress-* run sequentially    │  │  copy-files / delete-files run       │
  │                                 │  │  concurrently, ≤ 10 at a time        │
  └─────────────────────────────────┘  └──────────────────────────────────────┘
              both groups start at the same time

Phase 3 — Report (results sorted back to declaration order)

Test plan

  • rules::rule::tests::sync_rules_default_to_sync_mode — all 8 validation rules return Sync
  • rules::rule::tests::async_rules_return_async_mode — all 5 dynamic rules return Async
  • handle::tests::test_sync_rule_{success,failure} — existing sync behaviour unchanged
  • handle::tests::test_async_rule_{success,failure} — async rules propagate results correctly
  • handle::tests::test_mixed_rules_* — sync failure and async failure both surface
  • handle::tests::test_more_async_rules_than_concurrency_limit — 20 async rules with limit of 10 complete without deadlock
  • handle::tests::test_result_order_preserved — results always returned in declaration order
  • All 301 existing unit tests still pass (cargo test -p fisherman_core)
  • cargo clippy --all-targets -- -D warnings clean

🤖 Generated with Claude Code

Rules are now split into two execution modes based on what they do:

- **Sync** (default): branch-name-*, commit-message-*, suppress-files,
  suppress-string — run sequentially in a dedicated thread, one after another.
- **Async**: exec, shell, write-file, copy-files, delete-files — each gets
  its own OS thread and runs concurrently with the other async rules.

Both groups start simultaneously so sync validation and heavy file/process
operations overlap in time, minimising total hook latency.

Concurrency of async rules is bounded by a `tokio::sync::Semaphore` (default
limit: 10).  Scoped OS threads acquire permits via `Handle::block_on` which
is safe to call from non-tokio threads and does not require the caller to be
inside a tokio task.

Implementation details:
- Add `ExecutionMode::{Sync,Async}` enum and a `Rule::execution_mode()`
  trait method (defaults to `Sync`) in `fisherman_core/src/rules/rule.rs`.
- Five dynamic rule types override `execution_mode()` to return `Async`.
- `HandleCommand::exec` now has three phases: (1) sequential preparation
  (extend context, evaluate `when` conditions), (2) parallel execution via
  `std::thread::scope` + tokio semaphore, (3) report in declaration order.
- All new behaviour is covered by unit tests in `handle.rs` and `rule.rs`.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
@sonarqubecloud
Copy link
Copy Markdown

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant