Job creation is being done in two steps

[Tansito]

What is the expected enhancement?

From #1147 @akihikokuroda suggested that the current logic that creates a Job can be problematic due to that the scheduler may find the job between the current 2 save() and execute it without the environment information.

Two options that come to my mind are:

• Have a new state before QUEUED that reflects some kind of an under state preparation.
• Remove job.id from environment variables but I think we need to have it

Happy to hear your thoughts @akihikokuroda , @IceKhan13 , @psschwei 😄

[psschwei]

Adding a new state might be an issue... didn't someone want our states to map directly to the qiskit / runtime ones?

Assuming it is, could we add logic in the scheduler to say don't execute if jobid is null?

[Tansito]

Well this new state wouldn't need even a migration for old Jobs and so on and the mapping for the states was a suggestion from Caleb for those states that represents the same in qiskit / runtime. I would not be worried about it specifically. That being said, check by job.id is another solution. Pros and Cons that I see:

• cons:
  • To run a Job then we will need:
    • Check the status
    • Decrypt the environment variables
    • Check the value for the job.id
  • Logic a bit more confusing than just check a status in case we want to debug
• pros:
  • easier to implement, less places where we need to touch
  • status remains the same so we don't have new ones in our statistics to take them into account

From my point of view. I would go with @psschwei proposal by now with the condition that if we start to add exceptions to when we should run a Job then we should re-think the implementation. That has it sense? (Other proposals / opinions continue being welcome).

[psschwei]

For job status, the issue I was thinking of was #1039

[akihikokuroda]

I'm wondering why this save() is necessary.

[Tansito]

Good question @akihikokuroda . In my refactorization I found that we were using the job_id obtained from that save in the build_env_variables method in this next line. From what I know we were using it for traceability but maybe we could review it.

[akihikokuroda]

The Job.id is filled when the Job instance is created. The build_env_variables takes the Job.id from the job instance passed it. So the Job instance doesn't need to be saved to get the Job.id.

[Tansito]

Exactly, and the job instance is created in that point.

[Tansito]

This is exactly what I was trying to solve with the services @akihikokuroda . If there is another part of the code where we are creating jobs then we need to refactorize it to use the new service. Don't remove the service.

[Tansito]

Thank you @akihikokuroda