[Adam-Schildkraut]

Socket Mode messages can wait in the receive queue and Bolt's handler executor before middleware runs, so existing timings miss the delay before handling starts.

Both Bolt adapters expose the envelope ID and optional dispatch delay on the existing Request, so apps can record them in ordinary app.use(...) middleware. The delay includes both SDK queues and parsing; custom queues without receive timestamps report null. Middleware keeps its normal ordering and error handling, so metrics code must isolate its own recording failures. Acknowledgement and shutdown behavior are unchanged.

Existing processMessage(String) overrides, string listeners and custom queues remain supported. A package-private context carries timing through the existing string dispatch hook, then listeners and Bolt receive it explicitly. The context is cleared after use and on failure. Custom overrides that forward processing to another thread report unknown timing; they continue handling messages as before.

New tests cover both queue delays, duplicate deliveries, unknown timing, existing dispatch overrides, cleanup after failures and nested calls, and configured error-handler acknowledgements. Local websocket tests cover all three backends. The focused suite passes on Java 8 (11 tests) and Java 17 (13 tests, including Jakarta), using AWS dependency 2.29.24 within the declared range for local verification. The full SDK suite and live Slack traffic have not been tested.

Category (place an x in each of the [ ])

• bolt (Bolt for Java)
• bolt-{sub modules} (Bolt for Java - optional modules)
• slack-api-client (Slack API Clients)
• slack-api-model (Slack API Data Models)
• slack-api-*-kotlin-extension (Kotlin Extensions for Slack API Clients)
• slack-app-backend (The primitive layer of Bolt for Java)

Requirements

Please read the Contributing guidelines and Code of Conduct before creating this issue or pull request. By submitting, you agree to those rules.

[Adam-Schildkraut]

One thing I noticed while working on this: the two SocketModeApp implementations already share almost identical dispatch and acknowledgement logic, so this patch repeats the new timing calculation and listener notification loop in both.

The listener type and its state already live in the shared bolt module. Would you prefer moving the notification loop into a small shared helper there, or keeping it inline to follow the existing adapter structure?

[Adam-Schildkraut]

Sorry for the scary PR size! Production changes are +161/−31, but the 4 *Test.java files make up the last +356 / -3