[Feature Request] Add Retry to `translate` when using the `QCtrl` integration

[the-iron-ryan]

We've been testing the qcs client internally with the QCtrl flag enabled and noticed some timeouts when attempting to call translate on some large, iterative QAOA workloads. We've monitored our production logs here at Q-CTRL when running these tasks, and noticed that the compilation tasks are being handled correctly. They do take a while since this is a large circuit thats quite deep. Average compilation task time is ~50 seconds.

The client's translate call is timing out with the following error:

  File "/home/ssm-user/src/research-qccf-finance-optimization/qctrlQCCFresearchtools/platforms/rigetti_platform.py", line 159, in run
    executable = translate(
                 ^^^^^^^^^^
translation.TranslationError: Call failed during gRPC request: status: Unavailable, message: "unavailable", details: [], metadata: MetadataMap { headers: {"server": "awselb/2.0", "date": "Mon, 09 Jun 2025 18:27:52 GMT", "content-type": "application/grpc", "content-length": "0"} }

@erichulburd mentioned to us that a good possible solution here would be to have a retry around these translate calls. Possibly we could even have exposed timeout settings in the TranslationOptions? I know the submit function has similar settings available through the ExecutionOptions.

Attached is a full log from one of our QAOA runs with Rust debug logging enabled. Happy to help in anyway to get this implemented!

rigetti_output.log

[erichulburd]

What I'd suggest here is the ability to configure backoff parameters (and type - e.g. exponential vs linear), as well as predicate (i.e. Callable([Exception], bool)), on the QCS ClientConfiguration. We would probably want separate predicates for gRPC and Rest network calls. Because the idiom is QCSClient.load() on the Python side, we would want the ability to specify the configuration in the settings file itself, or some public methods on QCSClient to set the parameters and type.

[the-iron-ryan]

Hey @erichulburd is there anyway we can push for just a simple timeout increase to the default_backoff inside backoff.rs as a temporary solution? We need something that will at least increase the max_interval to > 50 sec to handle these large circuits.

I've opened up a PR to address this here. Lmk what you think 👍