QiskitRuntimeService.backends fails when a backend has a bad configuration

[wshanks]

Describe the bug

Sometimes the runtime service has a backend with bad data. Currently, an exception trying to load a backend object is allowed to bubble up to the caller of QiskitRuntimeService.backends().

Steps to reproduce

This bug is likely tricky to reproduce in production without mocking. It comes up more often in other runtime service instances. When there is bad configuration data in the service, it can be triggered by running service.backends().

Expected behavior

I expect that the caller of QiskitRuntimeService.backends() expects to get back a list of good backends. If there are badly configured backends, they could be warned about but I would not expect them to cause an error.

Suggested solutions

At this point:

qiskit-ibm-runtime/qiskit_ibm_runtime/qiskit_runtime_service.py

Lines 551 to 552 in 28487f6

	if backend := self._create_backend_obj(backend_name, instance=hgp):
	backends.append(backend)

the self._create_backend_obj() call could be put into a try block to guard against exceptions.

Additional Information

For the case most recently encountered, the exception that propagated up was of the form:

qiskit_ibm_runtime.api.exceptions.RequestsApiError: '404 Client Error: Not Found for url: https://api.quantum.ibm.com/runtime/backends/<misspelled_backend>/configuration

where <misspelled_backend> was the name of a private backend that had been added to the database somehow but misspelled and without any configuration data.

Another suggestion -- personally, I use backends to get a list of backends that the account I am using has access to. I really just need the list of names and don't need all the backends loaded. Maybe there could be a QiskitRuntimeService.backend_names property. That would not have issues with loading bad backends (that would be delayed until trying to load a backend).

• qiskit-ibm-runtime version: 0.29.0
• Python version: 3.11
• Operating system: RHEL 8

[kt474]

Following up on a slack conversation:

We already have a try/except check for invalid backend configurations here. The API error that happened in this case only happened because of a misspelled backend name.

Adding another try/except in _create_backend_obj may be worthwhile but these types of data entry errors shouldn't happen in the first place.