chain/indexer/src/block.rs (1)

339-345: Abort the background task on early‐error to avoid leakage.

If rx.next().await yields None you return an error but the indexing task (indexing_abort_handle) is left running in the background, potentially holding DB connections and CPU.
Ensure cleanup before bubbling the error:

-        } else {
-            Err(crate::errors::CoreEthereumIndexerError::ProcessError(
-                "Error during indexing start".into(),
-            ))
+        } else {
+            // stop the spawned task – it is either unhealthy or
+            // entered its completion path already
+            indexing_abort_handle.abort();
+            Err(crate::errors::CoreEthereumIndexerError::ProcessError(
+                "Error during indexing start".into(),
+            ))
         }

transport/probe/src/probe.rs (1)

179-181: Avoid moving out of self – clone the tuple instead.

let me = self.me; moves the (OffchainPublicKey, Address) out of self.
If either field is not Copy, the compiler will complain that self is partially moved and the rest of the method can no longer use it.
Clone (or borrow) instead:

-                    let me = self.me;
+                    let me = self.me.clone();

common/async-runtime/Cargo.toml (1)

20-26: Specify default-features = false if you only need AbortHandle.

futures pulls in a fair amount of optional code.
If the crate only relies on AbortHandle / abortable, disable the default feature set to keep your compile graph lean:

-futures = { workspace = true }
+futures = { workspace = true, default-features = false }

transport/protocol/src/lib.rs (2)

72-73: Redundant Box::pin indirection.

spawn_as_abortable accepts any Send + 'static future; execute_on_tick(...) already returns one.
Dropping the heap allocation trims an indirection and a Pin<Box<..>>:

-spawn_as_abortable(Box::pin(execute_on_tick(
+spawn_as_abortable(execute_on_tick(

---

155-156: Prefer a single AbortHandle type path for clarity.

Here the public signature binds to hopr_async_runtime::AbortHandle while the implementation receives the handle directly from futures::future::AbortHandle via spawn_as_abortable.
Keeping only the re-exported path avoids accidental type mismatch if the runtime stops re-exporting:

pub async fn run_msg_ack_protocol<Db>(...) 
    -> HashMap<ProtocolProcesses, AbortHandle> // import AbortHandle from hopr_async_runtime

hoprd/hoprd/src/main.rs (1)

258-270: Consider awaiting terminated tasks for graceful shutdown.

Calling AbortHandle::abort() is fire-and-forget; long-running clean-up work inside the tasks (flush logs, close sockets, persist state) may be dropped mid-flight.
If predictable shutdown is desirable, keep the JoinHandle (or a completion channel) and await it after aborting, or add a short timeout sleep before exiting.

hoprd/rest-api/src/session.rs (1)

900-906: Ignore abort() result?

AbortHandle::abort() is infallible but instant; if you want to be sure the listener is actually gone (e.g. to reclaim the port before recreating), keep the matching AbortRegistration or a completion signal and wait for confirmation before returning 204.

transport/probe/src/probe.rs (1)

173-177: Minor readability nit – pull the future out before spawning.

Long, nested expressions inside spawn_as_abortable are harder to read and debug. Extract the future into a variable first, then spawn:

-            hopr_async_runtime::spawn_as_abortable(direct_neighbors
-                .for_each_concurrent(max_parallel_probes, move |(peer, notifier)| {
+            {
+                let fut = direct_neighbors.for_each_concurrent(
+                    max_parallel_probes,
+                    move |(peer, notifier)| {
                         /* … */
-                })
-            )
+                    },
+                );
+                hopr_async_runtime::spawn_as_abortable(fut)
+            }

hopr/hopr-lib/tests/chain_integration_tests.rs (1)

807-808: Un-necessary async/join_all around abort()

AbortHandle::abort() is synchronous and returns ().
Wrapping each call in an async block and then join_alling adds overhead without benefit:

-futures::future::join_all(alice_node.node_tasks.into_iter().map(|ah| async move { ah.abort() })).await;
-futures::future::join_all(bob_node.node_tasks.into_iter().map(|ah| async move { ah.abort() })).await;
+for ah in alice_node.node_tasks { ah.abort(); }
+for ah in bob_node.node_tasks { ah.abort(); }

hopr/hopr-lib/src/lib.rs (2)

907-926: Session-server task is now abortable but for_each_concurrent ignores abort errors

AbortHandle::abort() will immediately short-circuit the stream future, but the internal closure swallows the Aborted result.
If you want to surface early termination (for metrics / debug), wrap the spawn in an async block and log the Err(Aborted).

That said, functionally this change is correct.

---

976-994: Strategy-tick now abortable – potential minor improvement

Aborting will instantaneously end the outer async block, but any in-flight on_tick() awaits will still run to completion.
If finer-grained cancellation is ever required, consider passing a cancellation token into on_tick().

No blocking change required for this PR.

common/async-runtime/src/lib.rs (1)

26-34: spawn_as_abortable drops the JoinHandle – consider exposing it

Right now the JoinHandle is assigned to _jh and immediately dropped, which means:

1. Panics inside the task are not observable.
2. You cannot .await completion for graceful shutdown.

A lightweight enhancement would be to return (AbortHandle, JoinHandle<Result<T, Aborted>>):

-pub fn spawn_as_abortable<F, T>(f: F) -> AbortHandle
+pub fn spawn_as_abortable<F, T>(f: F) -> (AbortHandle, prelude::JoinHandle<Result<T, futures::future::Aborted>>)
@@
-    let _jh = prelude::spawn(proc);
-    abort_handle
+    let jh = prelude::spawn(proc);
+    (abort_handle, jh)

Consumers that do not care about the JoinHandle can simply ignore the second tuple element, preserving ergonomics while enabling richer lifecycle management when needed.

transport/session/src/manager.rs (3)

356-362: Prefer a single AbortHandle path for clarity

start currently returns Vec<hopr_async_runtime::AbortHandle> while the file already imports futures::future::AbortHandle as AbortHandle.
Unless hopr_async_runtime::AbortHandle is a public type-alias, mixing the two paths is needlessly confusing.

-) -> crate::errors::Result<Vec<hopr_async_runtime::AbortHandle>> {
+) -> crate::errors::Result<Vec<AbortHandle>> {

Keeps the code self-consistent and avoids surprising type-path mismatches.

---

370-393: Loss of panic visibility after switching to spawn_as_abortable

spawn_as_abortable discards the underlying JoinHandle; panics in the spawned future will therefore be silently dropped.
If observing task failure is important, consider wrapping the future and logging / metrics-recording the result before returning the AbortHandle.

---

1183-1185: Unnecessary async hop when aborting handles in tests

AbortHandle::abort() is synchronous, so spawning an async loop adds overhead for no gain.

-futures::stream::iter(ahs)
-    .for_each(|ah| async move { ah.abort() })
-    .await;
+for ah in ahs {
+    ah.abort();
+}

Reduces test runtime and avoids an extra task.

transport/api/src/lib.rs (4)

39-40: Shadow-import of AbortHandle

The import adds AbortHandle from hopr_async_runtime, yet several modules rely on the re-export from futures.
Pick one path consistently (ideally the short unqualified one imported here) to avoid ambiguity.

---

271-272: Return type path consistency

Same note as in SessionManager::start: prefer the already-imported AbortHandle instead of the fully-qualified one for readability:

-) -> crate::errors::Result<HashMap<HoprTransportProcess, AbortHandle>> {
+) -> crate::errors::Result<HashMap<HoprTransportProcess, AbortHandle>> {

(only the path changed in the diff ‑ no semantic change).

---

380-382: HashMap now stores only AbortHandles – make key names reflect that

Variable names like processes still refer to “processes”, but inner variables later named jh were not adjusted (jh now holds an AbortHandle).
Renaming avoids mental friction for future readers.

---

542-566: Long-running dispatch loop swallows errors

Inside the abortable future, any error logged in dispatch_message is discarded.
If unintended, bubble the error out so test/ops can detect mis-behaviour before aborting:

if let Err(e) = smgr.dispatch_message(pseudonym, data).await {
    error!(%e, "error…");
    return Err(e); // let outer task log/panic if needed
}

Even logging the first error and breaking out would help operational visibility.

Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro