Slack Bolt deferred response loss after ack when process terminates

Designing reliable handling of acknowledgment timeouts and cancellation for Slack Bolt apps that use slash commands and interactive components. The supported flow requires an acknowledgment within Slack's 3-second window, with Bolt providing a configurable ack timeout and the ability to defer the full response via respond or say after ack.

The constraints are that ack must precede any long-running work, and once ack is sent there is no documented built-in mechanism to cancel a pending deferred response. Socket Mode uses a heartbeat for connection health, and rate-limit handling respects Retry-After, but cancellation of queued requests during backoff is not exposed.

The unresolved behavior concerns the fate of a deferred response when the app process terminates after ack but before respond is executed, and whether any notification is sent to Slack or the user. Clarity is also needed on cancellation semantics for in-flight work during reconnects.

Does Bolt expose a way to cancel or invalidate a deferred response after ack has been sent? What happens to a deferred response if the app process exits before respond is called? Is there SDK-level cancellation for in-flight API calls during Socket Mode reconnect or 429 backoff?