GenSpark AI Developer fbe94506f8 perf(wizard): parallelize Will-Executor broadcast in Building Will wizard ...

The Building Will wizard (BalBuildWillDialog.loop_push) still broadcast the
will to will-executors sequentially -- a for-loop calling
push_transactions_to_willexecutor one server at a time. This is the slow
"Broadcasting your will to executors: Trasmissione" step the user saw: a
slow/dead server blocked the whole wizard, just like the non-wizard path did
before it was parallelized.

Rewrite loop_push to use Willexecutors.push_transactions_parallel (the same
helper already used by window.push_transactions_to_willexecutors):
- Pre-filter to the user-selected will-executors only.
- Push to all selected servers concurrently (ThreadPoolExecutor); each server
  keeps its own retry behaviour, but a slow/dead server no longer blocks the
  others. Total time ~= slowest server, not the sum.
- on_each callback does thread-safe book-keeping + UI update via msg_edit_row
  (which emits a pyqtSignal marshalled to the GUI thread).
- 'already present' servers are collected and their stored tx verified
  sequentially afterwards (original check_transaction logic preserved).
- Preserve the retry flag and the _stopping cancellation checks.

tests/parallel_ping_test.py: add a static check asserting loop_push uses
push_transactions_parallel and no longer contains the sequential push loop.

Tests: 182 official + smoke/overflow/gui_fixes/parallel/external_zip all pass.
ruff: no new issues; new code is PEP8-compliant.

2026-06-28 22:51:28 -04:00

41 KiB

Raw Blame History

View Raw