Reliable delivery of a message is the responsibility of the transport. Successful delivery can mean very different things depending on context, see Quality of Service (QoS) 1, 2, 3. An ESB in a Service Oriented Architecture is normally responsible for routing and transformation as well as value add options such as monitoring, auditing etc.
A REST call should be an action on an object. It shouldn't take that long to complete and normally would be able to do the processing and return a HTTP response before it was a problem.
If you really need to send off an asynchronous message once a HTTP request comes in because the action takes a long time, then you are not going to be able to wait for the response. In this case it's not really the responsibility of your ESB to do something about it. You are really going to have to decide how your program deals with this. Your ESB may be able to help you with this, for example by coordinating a global transaction for you. If you have already replied to your HTTP requestor that the action has been taken in hand, just as an MQTT client is responsible for the message once it has acknowledge the message status with the server to the specified level of QoS, you need to treat this process failing as a failing transaction and either undo everything that happened or compensate for things that can't be rolled back. The originator then needs to be coded with the assumption of the same behaviour and know that it needs to check up on what really happened or inform the client.