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

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?