When postponing the delivery time of an already signed/sent will, the user
was asked to sign the on-chain invalidation transaction twice before the new
(postponed) will could be built.
Root cause: after the invalidation tx was broadcast, on_success_invalidate
restarted task_phase1 to rebuild the will, but the old will items were still
marked COMPLETE/PUSHED with their original tx.locktime (the on-chain
invalidation did not update the in-memory status). The postpone check therefore
fired WillPostponedException a second time, requesting another invalidation.
Fix:
- Add Will.mark_invalidated_by_tx(will, tx): marks INVALIDATED every valid will
item that spends a prevout consumed by the just-broadcast invalidation tx.
Setting INVALIDATED clears the VALID flag, removing those items from
only_valid_list so the postpone/expire check no longer fires.
- Call it from loop_broadcast_invalidating after a successful broadcast (txid
obtained) and persist via save_willitems. On the phase-1 restart the old will
is no longer VALID, so the will is rebuilt directly: a single invalidation
signature followed by the new will.
Tests: add test_will_mark_invalidated_by_tx and
test_will_mark_invalidated_by_tx_no_match plus the WillPostponedException
hierarchy assertion. 184 tests pass; smoke and external-zip OK; ruff clean.
Bump version to 0.3.1.
Problema: i server Will-Executor venivano contattati in sequenza e, su
timeout, send_request riprovava 10x con sleep 3s (~130s per server morto).
Un solo server irraggiungibile bloccava l'intera operazione (impallamento UI).
Soluzione:
- ThreadPoolExecutor: ping e push ora in parallelo (tempo ~= server piu' lento,
non la somma). Un server morto non blocca piu' gli altri.
- Fast-fail per operazioni interattive (ping/info/download): max_retries=0,
niente retry-storm.
- Feedback live: callback on_each() aggiorna il dialog server-per-server
(thread-safe via pyqtSignal di BalWaitingDialog.update).
- Push transazioni: parallelo ma con retry per-server mantenuti (no perdita tx).
File:
- bal/core/willexecutors.py: send_request(+max_retries,+retry_sleep),
get_info_task fast-fail, NEW ping_servers_parallel(), push_transactions_parallel(),
DEFAULT_TIMEOUT=5.
- bal/gui/qt/window.py: ping_willexecutors_task + push_transactions_to_willexecutors
riscritti su helper paralleli con feedback live; fetch_will_executors_list fast-fail.
- bal/core/util.py: BUGFIX get_value_amount usava in_output (bool) invece di
din_output (tupla) -> TypeError. Scoperto dai test ufficiali Gitea.
Test (contro il codice refactor):
- pytest tests/ ufficiali: 117 core + 65 gui = 182 passed.
- smoke/external_zip/windows_overflow/gui_fixes: OK.
- parallel_ping_test (nuovo): 0.50s per 8 server vs ~4.00s sequenziale.
- ruff: nessun nuovo problema introdotto (codice nuovo PEP8-compliant).
Aggiunti i test ufficiali del repo Gitea + REPORT_NETWORKING_PARALLELO.md.
Revert the v0.3.1 double-invalidation change (it caused an inheritance-list
regression: stale/invalidated wills lingered and heir/date updates became
incoherent) and add several targeted missed-update fixes plus a UI refinement.
Revert (v0.3.1 -> v0.3.2):
- Remove Will.mark_invalidated_by_tx() and its call in
loop_broadcast_invalidating. core/will.py and gui/qt/dialogs.py are restored
to the working v0.3.0 behaviour. The postpone double-invalidation issue is
intentionally left open, to be addressed without touching the shared
broadcast path.
FIX 1 - detect heir removal on Check / Electrum close:
- core/will.py (check_willexecutors_and_heirs): the else-branch now raises
HeirNotFoundException when a will still carries an heir that is no longer in
the current heirs set (heir removed), mirroring the existing 'heir added'
path. Rebuild therefore triggers on Check and on_close (same build_will_task
path), as decided by the user (manual update only, no auto-rebuild).
FIX 2 - Check queries servers for already-sent wills:
- core/will.py: new Will.needs_server_check(w) returns True for any VALID will
with a will-executor that is not yet CHECKED (no longer limited to PUSHED).
- gui/qt/lists.py (PreviewList.check): use needs_server_check so wills stuck on
'New / Not sent' are re-checked instead of reporting 'nothing to do'.
FIX 3 - Settings-dialog hide toggles refresh the list:
- core/plugin_base.py: new sync_hide_filters() re-reads the cached
_hide_invalidated / _hide_replaced flags from the persisted config.
- gui/qt/window.py (update_all): call sync_hide_filters() before refreshing, so
toggling 'Hide Invalidated' / 'Hide Replaced' in the Settings dialog (which
writes the config directly) updates the transaction list immediately instead
of requiring an Electrum restart.
UI - bold results in the Building Will dialog:
- gui/qt/dialogs.py (BalBuildWillDialog): render the right-side results in bold
(Ok, Ko, Nothing to do, Skipped, Wait, Timeout, ...) keeping the left-side
state labels in normal weight. Centralised in msg_ok/msg_error/msg_warning/
msg_set_status, plus the will-executor push/check rows now show Ok/Ko and
True/False in bold + colour (green/red).
Tests/tooling:
- tests/test_core_will.py: add test_check_heirs_unchanged_is_coherent,
test_check_heir_removed_triggers_rebuild, test_check_heir_added_triggers_rebuild,
test_needs_server_check.
- tests/sim_update_flows.py: real-world update-scenario simulation.
- tests/preview_build_will_dialog.py, tests/preview_we_rows.py: GUI-only
before/after previews of the bold formatting.
- Bump version to 0.3.2 (VERSION, manifest.json, __init__.py, plugin_base.py).
186 tests pass; smoke test, external-zip test and update-flow simulation OK;
ruff reports only pre-existing star-import false positives.
When postponing the delivery time of an already signed/sent will, the user
was asked to sign the on-chain invalidation transaction twice before the new
(postponed) will could be built.
Root cause: after the invalidation tx was broadcast, on_success_invalidate
restarted task_phase1 to rebuild the will, but the old will items were still
marked COMPLETE/PUSHED with their original tx.locktime (the on-chain
invalidation did not update the in-memory status). The postpone check therefore
fired WillPostponedException a second time, requesting another invalidation.
Fix:
- Add Will.mark_invalidated_by_tx(will, tx): marks INVALIDATED every valid will
item that spends a prevout consumed by the just-broadcast invalidation tx.
Setting INVALIDATED clears the VALID flag, removing those items from
only_valid_list so the postpone/expire check no longer fires.
- Call it from loop_broadcast_invalidating after a successful broadcast (txid
obtained) and persist via save_willitems. On the phase-1 restart the old will
is no longer VALID, so the will is rebuilt directly: a single invalidation
signature followed by the new will.
Tests: add test_will_mark_invalidated_by_tx and
test_will_mark_invalidated_by_tx_no_match plus the WillPostponedException
hierarchy assertion. 184 tests pass; smoke and external-zip OK; ruff clean.
Bump version to 0.3.1.
Problema: i server Will-Executor venivano contattati in sequenza e, su
timeout, send_request riprovava 10x con sleep 3s (~130s per server morto).
Un solo server irraggiungibile bloccava l'intera operazione (impallamento UI).
Soluzione:
- ThreadPoolExecutor: ping e push ora in parallelo (tempo ~= server piu' lento,
non la somma). Un server morto non blocca piu' gli altri.
- Fast-fail per operazioni interattive (ping/info/download): max_retries=0,
niente retry-storm.
- Feedback live: callback on_each() aggiorna il dialog server-per-server
(thread-safe via pyqtSignal di BalWaitingDialog.update).
- Push transazioni: parallelo ma con retry per-server mantenuti (no perdita tx).
File:
- bal/core/willexecutors.py: send_request(+max_retries,+retry_sleep),
get_info_task fast-fail, NEW ping_servers_parallel(), push_transactions_parallel(),
DEFAULT_TIMEOUT=5.
- bal/gui/qt/window.py: ping_willexecutors_task + push_transactions_to_willexecutors
riscritti su helper paralleli con feedback live; fetch_will_executors_list fast-fail.
- bal/core/util.py: BUGFIX get_value_amount usava in_output (bool) invece di
din_output (tupla) -> TypeError. Scoperto dai test ufficiali Gitea.
Test (contro il codice refactor):
- pytest tests/ ufficiali: 117 core + 65 gui = 182 passed.
- smoke/external_zip/windows_overflow/gui_fixes: OK.
- parallel_ping_test (nuovo): 0.50s per 8 server vs ~4.00s sequenziale.
- ruff: nessun nuovo problema introdotto (codice nuovo PEP8-compliant).
Aggiunti i test ufficiali del repo Gitea + REPORT_NETWORKING_PARALLELO.md.
