Ask the `ServerHelper` for fresh headers on every poll in `Future::get`, as is done for cookies

Open Beginner friendly
#5,886 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
77/100
Issue type
Feature
Clarity
Clearly specified
Activity status
Active
Tech stack
cpp
Domain
backend

Research direction

Start in runtime/common/Future.cpp and trace how Future::get builds headers and cookies for each status request in its polling loop. Check the ServerHelper implementations under runtime/ for how they provide headers. Update the polling requests to obtain fresh headers each time, then verify the relevant runtime tests cover repeated status requests with updated headers.

Written by the indexing model from the issue text.

Description

enhancement
Required prerequisites
  • Search the issue tracker to check if your feature has already been mentioned or rejected in other issues.
Describe the feature

What happens today. Future::get calls serverHelper->getHeaders() once, before the
loop over the jobs, and reuses that value for every status request. Cookies are different:
serverHelper->getCookies() is called again for every request.

// runtime/common/Future.cpp (same in 0.16.0 and on main today)
auto headers = serverHelper->getHeaders();          // once
...
auto resultResponse =
    client.get(jobGetPath, "", headers, false, serverHelper->getCookies());
while (!serverHelper->jobIsDone(resultResponse)) {
  ...
  resultResponse = client.get(jobGetPath, "", headers, false,
                              serverHelper->getCookies());   // every poll
}

Why it matters. A helper whose service wants a short-lived token in a header
(Authorization: Bearer ...) cannot renew it while a job waits. The poll requests keep
the token from the moment get() started.

I hit this while writing an out-of-tree backend for IBM Quantum
(cudaq-ibm-backend). IBM Cloud IAM
tokens live for about 60 minutes, and jobs on the open plan can wait in the queue for
longer than that.

The cookie path shows the pattern already exists: QuantinuumServerHelper::getCookies()
calls refreshTokens() and returns the token as a cookie, so it stays fresh during a long
poll. A helper that needs the token in a header has no equivalent. FermioniqServerHelper
may be in the same position: it puts its token in the Authorization header and calls
refreshTokens() inside jobIsDone(), but the poll requests still use the headers taken
before the loop. I only read that code, I did not run it.

What I ran. CUDA-Q 0.16.0 (source build), my out-of-tree plugin, and a fake server
that mimics the IBM endpoints and issues tokens that live 12 seconds
(script).
The helper polls every 5 seconds and returns a new token from getHeaders() whenever the
old one is about to expire. Server log:

login: issued fake-token-1, valid for 12 s      <- backend data
login: issued fake-token-2, valid for 12 s      <- job POST
login: issued fake-token-3, valid for 12 s      <- getHeaders() at the start of Future::get
poll 1 with fake-token-3 -> Running
poll 2 with fake-token-3 -> Running
poll 3 with fake-token-3 -> Running
401 for /api/v1/jobs/<id>: fake-token-3 expired 3.0 s ago

sample then throws HTTP GET Error - status code 401. The helper would have returned a
new token, but it was not asked.

What I did not run. The same failure against the real IBM service: that needs a job
that waits about an hour in the queue. I also did not run any in-tree backend.

Proposal. Call getHeaders() where getCookies() is called, for every poll request:

resultResponse = client.get(jobGetPath, "", serverHelper->getHeaders(), false,
                            serverHelper->getCookies());

Helpers that return constant headers behave as before. The cost is one more call per poll.
I read every getHeaders() under runtime/ on main: none makes a network request, they
build a small map. The IQM helper may read its token file there, so with this change it
would also pick up a token that was renewed in that file during a long wait.

I would like to implement this and can open a pull request if the approach is fine.

Dominant language
C++
Stars
1.2k
Forks
490
Avg merge
1d 5h
Merged PRs (30d)
191

Getting set up

Open in Codespaces

Starts the project's dev container in your browser, under your own GitHub account.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from NVIDIA/cuda-quantum

All issues in NVIDIA/cuda-quantum

Similar issues

More C++ issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.