Promise.setTimeout vs EventBus send timeout for graceful cancellation of long-running calls

A design is needed to fail service calls that exceed an SLA without leaving work running on the event loop or worker threads.

Vert.x Promise API supports promise.setTimeout(long, TimeUnit) which fails the Future with a TimeoutException when the duration elapses. The underlying async task is not cancelled by the timeout. The EventBus request/response pattern supports deliveryOptions.setSendTimeout(long) which aborts the client-side response Future after the timeout. The server-side handler continues processing unless it cooperatively checks cancellation.

The current behavior leaves resource cleanup to the application. Manual timeout logic with setTimer and cancel(timerID) provides explicit control but requires propagation to ongoing Futures or streams. There is an open design question about whether a timeout should be treated as a cancellation signal for the underlying operation.

Should a Promise timeout be considered a cancellation request that the application must propagate manually, or is it intended only as a failure signal for the caller? Is the EventBus message isCancelled() flag a reliable cooperative cancellation signal across verticles? How should long-running executeBlocking work be coordinated with a Promise or EventBus timeout to avoid leaks?