Rooki calls cancel method despite request completing successfully

[JamesVarndell]

@cehbrecht sometimes rooki attempts to call a cancel method in the middle of a workflow running - even when that request eventually succeeds on the server side. Here's the traceback we're getting from rooki:

  File "/home/cds/cdsservices/services/esgf_wps/requests.py", line 60, in process
    response = workflow.orchestrate()
  File "/usr/local/lib/python3.6/site-packages/rooki/operators.py", line 33, in orchestrate
    return rooki.orchestrate(workflow=self._serialise())
  File "</usr/local/lib/python3.6/site-packages/birdy/client/base.py-2>", line 5, in orchestrate
  File "/usr/local/lib/python3.6/site-packages/rooki/client.py", line 49, in _execute
    resp = super(Rooki, self)._execute(pid, **kwargs)
  File "/usr/local/lib/python3.6/site-packages/birdy/client/base.py", line 354, in _execute
    self._console_monitor(wps_response)
  File "/usr/local/lib/python3.6/site-packages/birdy/client/base.py", line 387, in _console_monitor
    execution.checkStatus(sleepSecs=sleep)
  File "/usr/local/lib64/python3.6/site-packages/owslib/wps.py", line 829, in checkStatus
    sleep(sleepSecs)
  File "/usr/local/lib/python3.6/site-packages/birdy/client/base.py", line 382, in sigint_handler
    self.cancel()
AttributeError: 'Rooki' object has no attribute 'cancel'
'}

[cehbrecht]

@JamesVarndell do you also have the rooki request for me?

[cehbrecht]

Strange thing :) The cancel method is only available when the notebook widgets are enabled (need to patch this in birdy). But I don't understand where signal comes from. It doesn`t look like a timeout as I first thought.

I can quick-fix it in rooki ... but need to have a proper fix in birdy.

[cehbrecht]

@JamesVarndell workaround added:
roocs/rooki#57

[cehbrecht]

Opened and issue in birdy:
bird-house/birdy#192