Develop Reference

When does Phoenix's Socket.js fire the onConnError vs the onError callbacks?

I'm writing an application that uses the Phoenix channels and phoenix's socket.js. I want to handle errors when the websocket can't connect (spotty Internet connection, etc.) and show an appropriate message.
Looking at the socket.js source code, there are two possible ways to register for errors on the Socket object. The first is
socket.onConnError(callback)
and the second is
socket.onError(callback)
I can trigger onError to be called by stopping the Phoenix server and trying to call socket.connect() in a browser. I can't seem to get socket.onConnError to fire though - when is it used? What are the differences between these two events/callbacks?

onConnError is not a way to register a callback for an error. onConnError is used to trigger an error. Calling onConnError will, in addition to some other things, call all the onError callbacks with the specified error message. It's called by the Socket class itself on any errors thrown by the connection object.

Looking more closely at the source code, looks like onConnError is used internally for actually triggering the onError callbacks that the user has registered.
Short answer: Use socket.onError.

Wait for an event to trigger inside Node.js process

First of all, I am well aware that Node.js is non-blocking before anything else, but in this very specific case, it must be blocking and waiting here.
I have an authentication process that works that way (using APIs, I didn't design this so I cannot modify the way the auth works):
I send a PUT request to a REST API, I get a HTTPResponse code that determines if the API understood the request.
The server I just requested through its API sends the full response (including error codes, etc) through an XMPP protocol.
This means, when I send the request, I cannot know what happened next, and must wait for the XMPP event to trigger (basically, an on("message", callback) event).
I'd like to know how to work with this with Node.js.
Two more things to know:
1) I'm working on a client/server architecture, and my Node.js server is doing this authentication process, and sending a response through the websocket to the client and waiting for a socket answer is out of the question (not my call, but my boss wants this process to be done in one pass).
2) It must not be done with the client socket and must go through the full Node.js process for various reasons.
Thanks a lot for your help people! \o/

Sorry for not answering previously, we had some severe hardware failure at work.
Anyway, I'm not answering one of your comments directly because I found a solution I prefer, even if I thank you for your help. I've decided to use a promise and to wait for its answer to be sure to get a proper response.
Here is the code:
var answer = await new Promise((accept, reject) => {
// If there are no stanza in 30 seconds, then the process failed or the stanza got missed.
setTimeout(() => {
reject("timed out");
}, (30 * 1000));
// Waiting for the xmpp event to trigger.
xmpp.on("stanza", function(stanza) {
// Processing of the received stanza goes here.
});
});
#gkatzioura solution was interesting, but this looked a little bit heavy on bandwidth and we are working on a large scale applications, or maybe I didn't fully understand it, then it is my mistake.
#pspi solution was also interesting but this would be a problem considering the XMPP event listener is inside the request, and the PUT request needs to send a body on its end() event and here it wouldn't really work for what I want to do. I think that's because the original post I made was somewhat unclear.
Thanks a lot for your help guys! :]

I don't know enough XMPP, but would this just be case of "putting dependent logic inside callback".
request.put(..., function () {
// dependent xmpp logic inside request callback
xmpp.on(..., function () {
// xmpp and put response received, now talk back to socket client
socket.send(...);
});
});

In your case I would proceed with the event emitter (or anything in a publish subscribe fashion).
Fire your http call and inside the handler add an emitter listener with a check if the events is for the corresponding authentication.
Meanwhile your xmpp connection once it receives the authorization it shall emit a message.
The listener will receive the message successfully and will use the callback of the http call.

Angular Jasmine SpyOn $resource Handle Errors

I am trying to unit test an AngularJS service that uses $resource. To keep it isolated, I would like to use Jasmine's spyOn and spy on the $resource's query() method. In my controller, I would like to be able to use the short form of query() where you pass a success and an error function directly to the query method without calling $promise.then(success, error). Is this possible, or am I stuck with the long form of query().$promise.then(success, error)?
Here is a plunker I created with a failing test illustrating my problem: http://plnkr.co/edit/hVc2YNnwUDNv7IHODOMD?p=preview
I have found several questions on SO claiming to solve the problem, but all are using much older versions of the components I am using. From the plunker you can see I'm working with Angular 1.5.2, and Jasmine 2.4.1.
As a related question, a number of tutorials show that in your controller, you can just assign the return value of query() to an array, and as the data is loaded, the array will be updated. This is the cleanest solution, but what happens if an error occurs? I would expect if there is a problem loading the data, you just end up with either some default error notification, or nothing happening at all. Is the best practice to handle errors elsewhere via an interceptor and maybe fire an event and notify the user in some generic non-controller specific way? I think then the interceptor would need some way of determining what message to display to the user to give some context, eg 'Loading of Bagels seems to be taking longer than usual, click here to retry' as opposed to 'some request returned a 500 status code'

You should still be able to use the function shorthand where you pass in the functions as query(success, error). To fix the unit test you need to account for the error function as shown below:
spyOn(mockBagelApiService, 'query').and.callFake(function(callback1, callback2) {
queryDeferred.promise.then(callback1);
queryDeferred.promise.catch(callback2);
return {$promise: queryDeferred.promise}
});
callFake will take in the parameters you pass into query() which are two functions for success and error. Depending on whether the promise has been resolved or rejected you need to handle the then and catch blocks with the appropriate callback.
The way i've handled request errors in my angular apps is by creating an error handler service that gets called in the catch block and will take in a specific error message and pop up a modal. You can configure it however you want: you can define the modal buttons to reload or redirect etc. For handling the message, you can configure your services to return problem codes that give a description of the situation such as USER_IS_NOT_AUTH or OAUTH_ERROR that your error handler can use to provide a more specific reponse.

Cloud Code function running twice

I have written a cloud function that is working well.
Sometimes this function is being executed more than one time for the same user (I made sure that only one request is being requested from the client android app).
After some debugging I noticed that this problem happens if the connection is bad. I may be or may not be correct.
How to overcome such an issue?

As in the comments I also don't believe the client SDKs would duplicate a Cloud Function call on a bad connection. The expected behaviour would be for them to throw a network-related exception on the client side and not call it again. A problem would arise if the Cloud Function runs successfully and the client is only unable to get the result back.
I can think of the following solutions, with no more details about the Cloud Function itself:
Try to make the function idempotent - Meaning that even if it runs twice the end result is the same, assuming the same input/parameters.
Cache the results and manually throttle the function - This is more complicated, and is only needed if the network problem persists and you can't work around eliminating the side effects of the function. You would have to create another Class to cache the results of the function (maybe keyed by the parameters) and returning the same result with no computation and side effects.

Is .fail() or .timeout() better in this case?

I need to handle timeouts on my $.ajax() calls for a jQueryMobile project. Doing some research I've come across two viable methods of doing this.
.error() .fail() seems to be generic: if the call fails for any reason then i'm kicked back an error stack, and then the function call is written to handle whatever I need it to.
.timeout, seems to let me deal specifically with timeouts and specify a time period that I can wait, if i don't receive an answer, then the call times out and throws an error.
My question is in a mobile environment, would it be better to handle timeouts with the .timeout() call? Or should I blanket all calls with the .error() .fail() function and handle timeouts within the error callback?
Working with mobile devices it is expected that a user may walk out of a coverage zone, so if the call never returns, my gut would say to implement a timeout function. Do error callbacks have a built in timeout? I would like to handle all errors gracefully, so it seems that maybe a happy medium would be implementing both, and specifying timeouts to work directly with the timeout callback.
Is there anything I might be missing here?

The timeout-event will trigger the fail()-function!
You should set a timeout-value for the $.ajax()-request.
$.ajax({
timeout: 15000 // 15sec
});
If the ajax-request hasn't recieved a response in this period of time it will excecute the function that has been passed in the .fail()-function.
$.ajax()
.fail(function(jqXHR, textStatus, errorThrown) {
if(textStatus === 'timeout') {
alert("$.ajax failed!");
{
});