support RF 3.1 about node-robotremoteserver HOT 8 OPEN

Hi @Snooz82 , how can it be reproduced? Please also provide node and robot versions.

from node-robotremoteserver.

I found out, that the node-robotremoteserver does not work with Robot version 3.1rc1 or newer.

https://github.com/starjumper30/node-robotremoteserver

between 3.1b1 (26.10.2018) and 3.1rc1 (25.11.2018) there was a change which makes it impossible to use asynchronous Keywords anymore.

If i run the Tests or the examples of this Library i get the following error.
[ ERROR ] Adding keyword 'doNothing' to library 'Remote' failed: Calling dynamic method 'get_keyword_arguments' failed: ResponseNotReady
of course with different Keywords.

with older robot versions it worked fine.

It is regarding the method get_keyword_types
the note remote server has not implemented this method and regarding Documentation it is not mandatory.

When i delete this from remote.py from class remote it works fine:

    def get_keyword_types(self, name):
        try:
            return self._client.get_keyword_types(name)
        except TypeError:
            return None

Any ideas?
Should i raise an issue?

from node-robotremoteserver.

New robot and old remote library works fine

from node-robotremoteserver.

https://github.com/starjumper30/node-robotremoteserver is a fork. Not the one publiished to npm as robotremote.
RF 3.1 is not tested, possibly the remote interface expectations changed meanwhile.

from node-robotremoteserver.

Ok. Independent of this fork it does not work.

from node-robotremoteserver.

It seems that the issue was in Robot Framework instead, and fixed in the RF 3.2: robotframework/robotframework#3300

from node-robotremoteserver.

Was it fixed in a minor version of RF3.1? Or 3.2 only?
How does #6 handles this?

from node-robotremoteserver.

#6 seems to support an optional feature introduced in RF3.1 (specify argument types), not sure why this should fix the robotframework/robotframework#3300. #6 can however be useful to cover such support.
Not sure why adding #6 was fixing the channel issue on RF3.1. It seems that their robotframework/robotframework#3300 fix is trying to not reuse the same xml-rpc http socket more than once, perhaps for some internal state issue in RF. The fix in in RF3.2 only.

from node-robotremoteserver.