@stevesoftwareservice @J. D. @Jeff (Wix) Thanks for the verification, very helpful. In this case, the doc error has a lot of impact, as the Promise may return in time to do the next thing or it may not, so it’s hard to catch in testing. Steven’s solution more or less sync’d up the Promise and the relocation. It may be a good idea to see if the relocation call should serialize before or after the logout call.
@jdavis I think adding a callback example to the docs would be a great addition, although this Promise.all([]) approach will work just as well in most cases.
@skmedia Sure, as long as the doc tells us the method returns a Promise.
@jonatandor35 The main reason the Promise.all() works is because all of the array members (whether a Promise or not) will be wrapped in a Promise by Promise.all().
This is the nature of how Promises work. Whenever you return a result from a Promise you get a Promise :-).
Also I’m thinking that wixUsers.logout() returns a Promise coincidentally because the wixUsers API is async. The problem is timing related to when the operation completes and any actions like page refresh occur.
Since the logout() is specified as a void it’s still probably wise not to relay on any Promise unless Wix make it “real”. 
@stevesoftwareservice
The reason why you can’t logout and right after that redirect to other page is that logging out ends by page refreshing which stops the code execution.
Now, wrapping the commands in Promise.all() shouldn’t resolve this issue (because the page may still refresh before redirection) unless , under the hood, logout() is really a promise and the page refresh runs when the promise gets resolved. In that case wrapping them, in Promise.all() will make sure both promises run before their resolution (i.e. before page refresh).
Am I right? Am I wrong?
@jonatandor35 Well that depends :-). The wix pages are all JavaScript generated since it’s an SPA. So it may depend on the browser loop and how Promises are resolved by the Browser ECMAScript engine. At this point why things do or don’t work is speculation (I don’t have the detailed architecture knowledge to deliver a factual answer).
@stevesoftwareservice @J. D. Pretty sure logout() is returning as a Promise. At some point I will serialize to test further what happens with the relocation call, I think @J. D. is probably right. Thanks for all the brain power!
@jdavis OK let’s put this one to bed. wixusers.logout() does not return a promise by design. Check out the video below. Is shows the auto complete in the wixEditor. It clearly shows what you should see if it DID return a Promise vs what it does return.
As you can see. If you try to add a “.” anything to the end of logout() it simply doesn’t know what you mean. By contrast applySessionToken() and emailUser() do return a Promise and the auto complete shows the catch and then options in the autocomplete options. QED! 
@stevesoftwareservice You’ve posted a video demonstrating the doc , not what happens when the script is run. Not sure why. The working code in the thread above demonstrates said doc is wrong, and if logout() on return is not handled as asynchronous then subsequent use of the return will be flawed. I frankly prefer working code, so my advice is use that. Fine with ending this thread, though.
@stevesoftwareservice @jdavis I have to agree with jdavis here…I’ve seen the Corvid linter fail enough to know that this isn’t a reliable test.
Also, Promise.all functions differently depending on what is inside the iterable:
-
An already resolved Promise if the iterable passed is empty.
-
An asynchronously resolved Promise if the iterable passed contains no promises. Note, Google Chrome 58 returns an already resolved promise in this case.
-
A pending Promise in all other cases. This returned promise is then resolved/rejected asynchronously (as soon as the stack is empty) when all the promises in the given iterable have resolved, or if any of the promises reject. See the example about “Asynchronicity or synchronicity of Promise.all” below. Returned values will be in order of the Promises passed, regardless of completion order.
In this case, I think it might be tripping up J.D. since this is essentially case 2, not 3.
Guys - what you are missing is that all wix api calls are wrapped in a Promise for the simple reason that the wix page is sandboxed in the browser and relies on web workers and backend services to deliver the API functionality.
The linter is “proxied” to show you what to expect back.
All api calls are translated into a postMessage call which is wrapped in a Promise otherwise no responses from the APIs would be returned.
So the actual logout function is independent of the browser worker and not designed to return anything. Which is what the editor linter is showing. The fact that the logout is wrapped in a Promise does not make the Promise outcome (resolve vs reject) reliable since you can’t rely on the logout actually waiting for anything in the then to execute (it is a fake Promise :-)).
Here the API code:
function logoutCurrentUser(appDefinitionId) {
return new Promise(function (resolve, reject) {
_wixcodeSdk.core.postMessage.sendMessageToHost(_wixcodeSdk.core.postMessage.Intent.WIX_CODE_SITE_API, {
command: _wixcodeSdk.core.postMessage.MessageTypes.SM_LOGOUT,
appDefinitionId: appDefinitionId,
callback: function callback(data, error) {
if (error) {
reject(error);
} else {
resolve();
}
}
});
});
}
@stcroppe My only intent was to say the test is unreliable, which I stand by as a linter is a program like any other and thus vulnerable to human error
And also to note that Promise.all would work reliably whether logout returns a promise or not, and so it is also not a good test. @jdavis ’ test seems most likely to be the best indicator, and if she’s right then the docs should reflect that.
@skmedia (“she’s right” … gender female) Each of us of course will make our own decisions. I’m thinking @stcroppe will probably stay with his original Promise.all solution, for which again he deserves thanks.
@jdavis Fixed for posterity The fact that Promise.all works whether the Corvid docs are right or not is a credit to the people who developed it, and ofc thanks Steve as well.
@stevesoftwareservice Just come acorss this post. EXCELLENT - This has saved me hours of messing about !!