When Session.from_id is called, internally it callscls(service, backend) to create a Session instance, with backendset to a string. Unless it's intentional to suppress warnings from Session.__init__ when called from Session.from_id, this should raise two deprecation warnings (one for passing a service and one for backend as a string), but raises none.
Steps to reproduce
First, create a session instance and grab the ID:
from qiskit_ibm_runtime import Session, QiskitRuntimeService
service = QiskitRuntimeService() # account info previously saved
backend = service.least_busy(operational=True, simulator=False)
session = Session(backend=backend)
session_id = session.session_id
Next, regenerate the session from its ID:
regenerated_session = Session.from_id(session_id, service) # produces no warnings
Expected behavior
Deprecation warnings raised for service and backend as a string, as for example when I use Session.__init__ directly:
backend = service.least_busy(operational=True, simulator=False)
session = Session(service=service, backend=backend.name)
/var/folders/7_/rsgnsxr55d32q72f3m991h5r0000gn/T/ipykernel_33497/3846134487.py:6: DeprecationWarning: The service parameter is deprecated as of qiskit-ibm-runtime 0.26.0 and will be removed no sooner than 3 months after the release date. The service can be extracted from the backend object so it is no longer necessary.
session = Session(service=service, backend=backend.name)
/var/folders/7_/rsgnsxr55d32q72f3m991h5r0000gn/T/ipykernel_33497/3846134487.py:6: DeprecationWarning: Passing a backend as a string is deprecated as of qiskit-ibm-runtime 0.26.0 and will be removed no sooner than 3 months after the release date. Use the actual backend object instead.
session = Session(service=service, backend=backend.name)
Suggested solutions
Not sure how to solve the problem in its entirety, but part of the issue seems to be how issue_deprecation_msg is used in Session.__init__. As used there, the stacklevel passed to warnings.warn is 3 (default value of 2, plus one), which works when a session is created via __init__ directly. In that case, the stack is: issue_deprecation_msg -> Session.__init__ -> caller. But when Session.from_id is used, the stack is too deep: issue_deprecation_msg -> Session.__init__ -> Session.from_id -> caller.
Desribe the bug
When
Session.from_id
is called, internally it callscls(service, backend)
to create aSession
instance, withbackend
set to a string. Unless it's intentional to suppress warnings fromSession.__init__
when called fromSession.from_id
, this should raise two deprecation warnings (one for passing a service and one for backend as a string), but raises none.Steps to reproduce
First, create a session instance and grab the ID:
Next, regenerate the session from its ID:
Expected behavior
Deprecation warnings raised for service and backend as a string, as for example when I use
Session.__init__
directly:Suggested solutions
Not sure how to solve the problem in its entirety, but part of the issue seems to be how
issue_deprecation_msg
is used inSession.__init__
. As used there, thestacklevel
passed towarnings.warn
is 3 (default value of 2, plus one), which works when a session is created via__init__
directly. In that case, the stack is:issue_deprecation_msg
->Session.__init__
-> caller. But whenSession.from_id
is used, the stack is too deep:issue_deprecation_msg
->Session.__init__
->Session.from_id
-> caller.Additional Information