AskTimeoutException in Akka's ask pattern: who cancels the actor's in-flight work?

Question

The ask pattern (Patterns.ask in classic Akka, or the ask methods on typed actors) fails the returned future with AskTimeoutException when no reply arrives within the configured timeout. That failure describes only the waiting side. The target actor is not interrupted, and any work it already started — a long computation, a blocking call, a downstream request — continues unless the caller or the actor itself arranges cancellation.This leaves a design gap in Akka 2.x, in both the classic and typed APIs: the timeout and the cancellation path are decoupled. A caller that retries after AskTimeoutException can trigger duplicate side effects, because the first request may still be executing. Akka Streams take a different stance — idleTimeout and completionTimeout fail the stream rather than leave it stalled — but the ask pattern offers no equivalent link to the target's ongoing work.The open decision is where cancellation responsibility belongs:Should callers send an explicit cancel message on timeout, and how should the actor reconcile it with the original request?Should the actor enforce its own deadline and treat the ask timeout as advisory?Does the answer differ between classic and typed actors, given their differing ask signatures?

Tasadduq Burney · Answer

AskTimeoutException – No Automatic CancellationWhen ask times out, the returned Future (classic) or CompletionStage (typed) is completed with AskTimeoutException. The target actor receives the original message normally and continues processing. The ask mechanism does not send any interrupt, kill, or cancellation signal to the actor.Confirmed Facts (Akka 2.6.x and 2.8.x)The timeout logic lives solely in the caller’s ask helper (scheduling a timer that completes the promise). It never touches the recipient actor.Both classic Patterns.ask and typed ActorRef.ask share this behaviour; the only difference is the API surface.Actor work that is already underway – long calculations, blocking I/O, downstream requests – continues to run unless the actor itself is programmed to stop or the caller sends an explicit cancel message.Practical Steps for a Timeout‑Retry ScenarioDetect the timeout: Handle the AskTimeoutException in the caller’s future.Decide on cancellation:
If the operation can be aborted, send an explicit cancel message (e.g., CancelRequest(id)) to the actor after the timeout.Ensure the actor’s behaviour includes a case for the cancel message and aborts the in‑flight work (e.g., by dropping a promise, closing a DB transaction, or interrupting a blocking call).Actor‑side deadline (optional):
Use context.setReceiveTimeout (classic) or Behaviors.withTimers (typed) to enforce a hard deadline inside the actor. Treat the ask timeout as advisory.When the internal deadline fires, the actor can reply with a Failure or simply stop processing.Idempotency safeguards:
When retries are possible, design the actor’s side effects (DB writes, external calls) to be idempotent or guarded by a unique request ID.When to Ask for More DetailIf your actor performs blocking operations (e.g., JDBC, legacy HTTP client) that do not honour thread interrupts, the explicit cancel message may not stop the work. In that case, consider moving the blocking call to a dedicated dispatcher or using an interruptible API.

AskTimeoutException in Akka's ask pattern: who cancels the actor's in-flight work?

1 answer

AskTimeoutException – No Automatic Cancellation

Confirmed Facts (Akka 2.6.x and 2.8.x)

Practical Steps for a Timeout‑Retry Scenario

When to Ask for More Detail

Your perspective belongs here.

0 question comments