-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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
Adding test suite for testing IBMQJob in isolation. #515
Adding test suite for testing IBMQJob in isolation. #515
Conversation
test/python/test_ibmqjob_states.py
Outdated
|
||
def run_job(self, *_args, **_kwargs): | ||
time.sleep(0.2) | ||
return {'error': 'ivalid test qobj'} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
typo here "invalid"
0becd31
to
a105d5b
Compare
qiskit/backends/ibmq/ibmqjob.py
Outdated
# pylint: disable=arguments-differ | ||
def result(self, timeout=60, wait=5): | ||
self._wait_for_initialization(timeout=timeout) | ||
result = self._wait_for_job(timeout=timeout, wait=wait) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the expectation for timeout
will be the maximum time for the result
call to return. Perhaps we can instead start a clock here (timeout_time = time.time() + timeout
) and pass timeout_time
to _wait_for_initialization
and _wait_for_job
.
qiskit/backends/ibmq/ibmqjob.py
Outdated
if self._future_submit.exception(): | ||
self._exception = self._future_submit.exception() | ||
self._status_msg = str(self.exception) | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How does this PR handle exceptions raised by self._future_submit
which is done async and may occur later?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Notice that reading status
will be stuck in the INITIALIZING
state until the initialization routine _submit
changes the internal job status.
All the errors happening inside the _submit()
are silenced (except for one case I just realize, thanks!) and stored inside the _exception
member, the internal status progress to JobStatus.ERROR
in these cases.
This causes all future reads to status
to skip querying the API since the job is in one of the final states.
Both tests test_status_flow_for_invalid_job
and test_status_flow_for_throwing_api
test the job in the cases when the job is invalid (and the API rejects it by raising an ApiError
) or the network side fails somehow (and the API returns an errored result) respectively. Anyway, I'll reinforce the tests in the next commits, checking the exceptions to get more confidence in the paths we are following.
Hope it helps.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is an error in my assumptions regarding _submit()
progressing the job to a final state. This final assignment happening at the end of the method invalidates de second paragraph of the explanation. I'll fix in the next commit. Thanks for the heads-up.
ffd3ba0
to
acdfd57
Compare
Everything is fixed now. What about a second review? |
a3fd9e7
to
e13056d
Compare
test/python/test_ibmqjob_states.py
Outdated
|
||
"""IBMQJob states test-suite.""" | ||
|
||
import unittest |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For the new files, can you adjust the license header so it follows the format recently introduced by #550 ?
# -*- coding: utf-8 -*-
# Copyright 2018, IBM.
#
# This source code is licensed under the Apache License, Version 2.0 found in
# the LICENSE.txt file in the root directory of this source tree.
# pylint: disable=something-only-if-there-is-no-other-way
"""
Description of the module ...
"""
from qiskit import ...
e13056d
to
bf0efec
Compare
This commit incorporates improvements from PR Qiskit#515 by @delapuente to handling job status such that it makes fewer api calls. Co-authored-by: [email protected]
bf0efec
to
9eaf078
Compare
@delapuente @ewinston not sure how to handle this PR. As this is going to test Jobs, and Ericks PR #501 (jobs from Backend) is hughly changing IBMQJob... we would need to have them sync. |
Since #501 is tagged as "high priority" and it's an earlier PR perhaps it should be the other way around. |
f5daa11
to
06c3a10
Compare
@delapuente is this PR rebased after #501 got merged? |
Does this solve #234? |
Yes. Since the implementation of IBMQJob changed noticeably, I've discarded most of my changes from the original PR but that's the only difference.
Not yet. It contributes to that but it is not replacing the original IBMQJob suite and more work is needed in other parts of the library. |
this_result = self._wait_for_job(timeout=timeout, wait=wait) | ||
except TimeoutError as err: | ||
# A timeout error retrieving the results does not imply the job | ||
# is failing. The job can be still running. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good point, but the Result has an ERROR status, so for the user something wrong happened with this Job. Should we state in any way, that this may not be a real Job error?... like having another status for "TIMEOUT" or something similar.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's mark this for future improvements... we need to merge this asap.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See #588 for the follow-up.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When job cancellation works on all IBM Q systems timeout could use that to cancel the job, which could be considered an error.
The test suite does not require network connection. It fakes the QJOB object and the API behaviour.
06c3a10
to
290e28d
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks everyone for the effort!
* Adding test suite for testing IBMQJob in isolation. The test suite does not require network connection. It fakes the QJOB object and the API behaviour. * Removing QuantumJob * Adding expected failure when cancelling during initialization
The test suite does not require a network connection. It fakes the QJOB object and the API behaviour.
This commit partially refactors the
IBMQJob#status()
method to avoid raising exceptions while reading a property.Motivation and Context
Current tests behave as integration tests so, in case of failure, it is not guaranteed the problem arises from IBMJob-related abstractions malfunctioning.
Checklist: