#949 (fixed in #1030) addressed a graceful-shutdown panic in ConsensusSessionOwned::spawn_blocking (components/consensusmanager/src/session.rs): on runtime teardown a queued blocking task is cancelled, the join returns Err(JoinError::Cancelled), and .await.unwrap() panics a worker thread.
The same spawn_blocking(...).await.unwrap() pattern appears elsewhere with the same shutdown-cancellation panic surface:
mining/src/manager.rs — MiningManagerProxy methods (get_realtime_feerate_estimations, get_transaction, has_transaction, transaction_count, get_all_transactions, get_transactions_by_addresses, has_accepted_transaction, unaccepted_transactions, unknown_transactions). Structurally identical to the session proxy and RPC-reachable.indexes/utxoindex/src/core/api/mod.rs — UtxoIndexProxy methods (get_circulating_supply, get_utxos_by_script_public_keys, get_balance_by_script_public_keys, update). Same proxy pattern, RPC-reachable.protocol/flows/src/ibd/flow.rs:163, 602 — staging commit / consensus reset during IBD.components/connectionmanager/src/lib.rs:257, 281 — dns_seed spawn_blocking / try_join_all.
(Sim/test code such as simpa and testing/integration excluded as lower priority. The async-runtime shutdown orchestrator in core/src/task/runtime.rs and the timeout-wrapped join in utils/src/sync/rwlock.rs are excluded as different semantics.)
Suggested approach
Apply the same handling as #949: on is_cancelled() (runtime shutdown, no result to return) park until teardown; on a genuine closure panic propagate via resume_unwind. This could be factored into a small shared helper (e.g. in kaspa-core/kaspa-utils) so the proxies/flows reuse it instead of open-coding .await.unwrap().
Filed separately from #949 to keep that fix scoped to the observed crash site.
#949 (fixed in #1030) addressed a graceful-shutdown panic in
ConsensusSessionOwned::spawn_blocking(components/consensusmanager/src/session.rs): on runtime teardown a queued blocking task is cancelled, the join returnsErr(JoinError::Cancelled), and.await.unwrap()panics a worker thread.The same
spawn_blocking(...).await.unwrap()pattern appears elsewhere with the same shutdown-cancellation panic surface:mining/src/manager.rs—MiningManagerProxymethods (get_realtime_feerate_estimations,get_transaction,has_transaction,transaction_count,get_all_transactions,get_transactions_by_addresses,has_accepted_transaction,unaccepted_transactions,unknown_transactions). Structurally identical to the session proxy and RPC-reachable.indexes/utxoindex/src/core/api/mod.rs—UtxoIndexProxymethods (get_circulating_supply,get_utxos_by_script_public_keys,get_balance_by_script_public_keys,update). Same proxy pattern, RPC-reachable.protocol/flows/src/ibd/flow.rs:163, 602— staging commit / consensus reset during IBD.components/connectionmanager/src/lib.rs:257, 281— dns_seedspawn_blocking/try_join_all.(Sim/test code such as
simpaandtesting/integrationexcluded as lower priority. The async-runtime shutdown orchestrator incore/src/task/runtime.rsand the timeout-wrapped join inutils/src/sync/rwlock.rsare excluded as different semantics.)Suggested approach
Apply the same handling as #949: on
is_cancelled()(runtime shutdown, no result to return) park until teardown; on a genuine closure panic propagate viaresume_unwind. This could be factored into a small shared helper (e.g. inkaspa-core/kaspa-utils) so the proxies/flows reuse it instead of open-coding.await.unwrap().Filed separately from #949 to keep that fix scoped to the observed crash site.