It's guaranteed to return as soon as the thread of execution finishes prior immediately-pending callbacks (since it's basically a synchronous function call with

It's guaranteed to return as soon as the thread of execution finishes prior immediately-pending callbacks (since it's basically a synchronous function call with an awaited return value). It's "finished" as soon as it's finished initiating the send, since it doesn't await the result. (The exact point where this gets resolved, relative to other pending callbacks/resolutions, is a very wonky detail involving constructs not exposed at the language level, which varies from engine to engine in spite of what the standard says: https://jakearchibald.com/2015/tasks-microtasks-queues-and-schedules/ https://jakearchibald.com/2015/tasks-microtasks-queues-and-s...) Whenever the call resolves, even if the send does encounter errors, this function or its caller aren't going to know about it either way. That's why this kind of promise-abandonment is pretty bad design - I wouldn't be surprised if there's already a draft in the works for some kind of "use strict" option that causes warnings / crashes when synchronous code finishes with Promises unreferenced (or at least something in tooling / profiling to trace 'promise leaks').