Fix threads in offline deployment

[t0mdavid-m]

Summary by CodeRabbit

• Refactor

  • The Threads input was unified into the standard widget system for consistent behavior and state synchronization.

• New Features

  • Threads setting now reads/writes persisted local configuration so the chosen thread count is retained across sessions and uses a labeled numeric control ("Threads").

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[coderabbitai]

Warning

Rate limit exceeded

@t0mdavid-m has exceeded the limit for the number of commits that can be reviewed per hour. Please wait 9 minutes and 30 seconds before requesting another review.

⌛ How to resolve this issue?

After the wait time has elapsed, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

We recommend that you space out your commits to avoid hitting the rate limit.

🚦 How do rate limits work?

CodeRabbit enforces hourly rate limits for each developer per organization.

Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout.

Please see our FAQ for further information.

📝 Walkthrough

Walkthrough

Replaced Streamlit direct number input with the unified input_widget for the max-threads control, added parameter-backed retrieval of max threads via a new optional parameter_manager argument in get_max_threads, and updated CommandExecutor to pass its ParameterManager when requesting max threads.

Changes

Cohort / File(s)	Summary
UI: max-threads input src/workflow/StreamlitUI.py	Replaced direct Streamlit number_input with input_widget(key="max_threads", widget_type="number", name="Threads"); removed previous value/key override bindings and tied the control into the unified input path.
Parameter access logic src/common/common.py	Updated get_max_threads signature to get_max_threads(parameter_manager=None) -> int; when local, reads persisted params via parameter_manager (if provided) to return an overridden max_threads, otherwise falls back to local default; online behavior unchanged.
Executor: pass ParameterManager src/workflow/CommandExecutor.py	Updated calls in run_multiple_commands and run_topp to call get_max_threads(self.parameter_manager) so executors receive parameter-backed thread counts.

Sequence Diagram(s)

sequenceDiagram
    participant UI as UI (Streamlit input_widget)
    participant Sess as SessionState
    participant PM as ParameterManager
    participant Common as common.get_max_threads
    participant Exec as CommandExecutor

    rect rgba(200,200,255,0.5)
    UI->>Sess: render/input `max_threads` (key="max_threads")
    Sess-->>PM: persist/reflect param (optional)
    end

    rect rgba(200,255,200,0.5)
    Exec->>Common: get_max_threads(parameter_manager=PM)
    Common->>PM: load persisted params (local path)
    PM-->>Common: return persisted max_threads (or none)
    Common-->>Exec: resolved max_threads
    end

    rect rgba(255,200,200,0.5)
    Exec->>Exec: schedule/run commands using max_threads
    end

Loading

Possibly related PRs

• Add configurable thread limits for parallel command execution #332: Changes to the threads UI, get_max_threads logic, and executor thread usage that appear closely related to this PR's thread-control refactor.

Poem

🐰 I hopped from input to key,
Threads now follow where parameters be,
A little manager saved the day,
Executors fetch the count and play,
Hop, hop — concurrency on its way!

🚥 Pre-merge checks | ✅ 3

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title accurately describes the main change: integrating the ParameterManager to allow configurable max threads in offline/local deployments.
Docstring Coverage	✅ Passed	Docstring coverage is 80.00% which is sufficient. The required threshold is 80.00%.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch claude/configurable-max-threads-Wr7B9

---

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

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

[coderabbitai]

Actionable comments posted: 1

🤖 Fix all issues with AI agents

In `@src/common/common.py`:
- Around line 35-55: get_max_threads may return zero, negative or non-int values
from settings or the UI override which can cause Semaphore(0) deadlocks or
divide-by-zero in threads_per_command; update get_max_threads to coerce the
chosen value to an integer and clamp it to a minimum of 1 before returning
(validate values coming from max_threads_config.get("local"/"online") and
st.session_state.get("max_threads_override") and ensure any non-numeric input
falls back to the configured default then to 1). Ensure the function references:
get_max_threads, max_threads_config, and the "max_threads_override" session key
are used when determining/normalizing the returned value.

🧹 Nitpick comments (2)

src/workflow/StreamlitUI.py (1)

1111-1122: Consider capping “Threads” to available CPU cores.

This prevents accidental oversubscription on local runs and keeps UI intent aligned with host capacity.

♻️ Proposed tweak

         if not st.session_state.settings.get("online_deployment", False):
             # Initialize session state with default if not set
             if "max_threads_override" not in st.session_state:
                 max_threads_config = st.session_state.settings.get("max_threads", {})
                 st.session_state.max_threads_override = max_threads_config.get("local", 4)
+            max_cpu = os.cpu_count() or 1
             st.number_input(
                 "Threads",
                 min_value=1,
+                max_value=max_cpu,
                 key="max_threads_override",
                 help="Maximum threads for parallel processing. Threads are distributed between parallel commands and per-tool thread allocation."
             )

src/workflow/CommandExecutor.py (1)

35-78: Prefer a bounded ThreadPoolExecutor instead of spawning one thread per command.

Even with a semaphore, this still creates N threads; a pool limits thread count and reduces overhead for large batches.

♻️ Proposed refactor

     def run_multiple_commands(
         self, commands: list[str]
     ) -> bool:
@@
         max_threads = get_max_threads()
         num_commands = len(commands)
         parallel_commands = min(num_commands, max_threads)
 
+        if num_commands == 0:
+            self.logger.log("No commands to run.", 1)
+            return True
+
         # Log the start of command execution
         self.logger.log(f"Running {num_commands} commands (max {parallel_commands} parallel, {max_threads} total threads)...", 1)
         start_time = time.time()
 
-        results = []
-        lock = threading.Lock()
-        semaphore = threading.Semaphore(parallel_commands)
-
-        def run_and_track(cmd):
-            with semaphore:
-                success = self.run_command(cmd)
-                with lock:
-                    results.append(success)
-
-        # Initialize a list to keep track of threads
-        threads = []
-
-        # Start a new thread for each command
-        for cmd in commands:
-            thread = threading.Thread(target=run_and_track, args=(cmd,))
-            thread.start()
-            threads.append(thread)
-
-        # Wait for all threads to complete
-        for thread in threads:
-            thread.join()
+        from concurrent.futures import ThreadPoolExecutor
+        with ThreadPoolExecutor(max_workers=parallel_commands) as pool:
+            futures = [pool.submit(self.run_command, cmd) for cmd in commands]
+            results = [f.result() for f in futures]