valeriansaliou / node-sonic-channel

🦉 Sonic Channel integration for Node. Used in pair with Sonic, the fast, lightweight and schema-less search backend.

Home Page:https://www.npmjs.com/package/sonic-channel

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Promisse on generic does not resolve (endless loading)

JorbFreire opened this issue · comments

I just found and kinda fixed a bug that makes absolutely no sense, and that's why I'm opening an issue and not a pull request.

Context:

I was working on this API that was already working, there was no reasonable reason to not, but sonic decide to not work today without any change on code or update on his version.
To be fair I was using a new container to sonic (and change it again a couple of times, never nows...)

Resolution (Work-around):

One promise was not returning proper callback, twice.
On lib/channel/geniric.js line 306 where he got the following methods, I just add a return this "return" on line 311. Tested inject and search, both work.
Them, cleaning the mess made debugging (Some try/catch blocks on client, logs on client and sonic-channel) the search method stopped working.
Added this work-around resolve() on line 318 and fixed for now.

SonicChannelGeneric.prototype._wrapDone = function(fn_operation) {
  var self = this;

  return new Promise(function(resolve, reject) {
    // Wrap operation 'done' callback with a 'Promise'
    return fn_operation.call(self, function(data, error) {  // line 311
      if (error) {
        return reject(error);
      }

      return resolve(data);
    });
    return resolve({some: 'thing'});  // line 318
  });
};

Extra information

Find out some calls for __client related to the _executeOrDefer. Looks important but his value was ways empty and triggering the defer not allowing the __execute. But after my work-around, it's working anyway, not sure why.
It's related to some socket.io connection or something like that, totally independent of the connection I'm using?
Also, would be a little weird because the only value attribution to __client appear to be a chain of functions calling each other where the "head" is never called or callable (once its private)