Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Promisse on generic does not resolve (endless loading) #15

Open
JorbFreire opened this issue Jan 10, 2022 · 0 comments
Open

Promisse on generic does not resolve (endless loading) #15

JorbFreire opened this issue Jan 10, 2022 · 0 comments

Comments

@JorbFreire
Copy link

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)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant