Need Job.restart() Api

[stefanusayudha]

Use case
API to restart a job.

Explain what specifically you are trying to do and why.

• It has a cancel operation but don't have restart
• To restart a job requires to create a new job as well as reproducing all component , or values, or parameters, or arguments require by the job to work. Those arguments and parameters sometimes hard to reproduce.
• In the other hand the previous job already have all the information to launch a process.
• In case of a job return error due to some issue, we should be able to restart the job to restart the process.
• We are not always able to restart the job automatically because some protocol might be required to restart the process, like user intention for example.
• In case error happen let say due to temporary IO error, it would be nice to simply call job.restart()

The Shape of the API

fun Job.restart()

[fvasco]

It has a cancel operation but don't have restart

Thread neither.

To restart a job requires to create a new job as well as reproducing all component , or values, or parameters, or arguments require by the job to work. Those arguments and parameters sometimes hard to reproduce.

It doesn't look too hard to me.

val task: CoroutineScope.() -> Unit = { TODO() }
// start task
launch(block = task) .join()
// restart task
launch(block = task) .join()

In the other hand the previous job already have all the information to launch a process.

Yes, but you should review the Job's state machine, too.

In case of a job return error due to some issue, we should be able to restart the job to restart the process.

Deferred is a Job, a Deferred should be completed twice, one with an error, other with a result?

We are not always able to restart the job automatically because some protocol might be required to restart the process, like user intention for example.

What is the expected behavior?
How launch a restartable job and a non restartable job?

[dkhalanskyjb]

This API will certainly not be added, at least because it introduces a huge risk of race conditions: if you start a Job, await its completion, and then restart it, then a job that was completed is suddenly un-completed again. This goes directly against the recommended approach of structuring your code with clear data dependencies, where jobs await the results of other jobs. Additionally, no, in general, Job itself is only tracking the lifetime of something, it doesn't know which code is associated with it, so this is not even easy to do.

Also, "API to restart a job" is not a use case. The issue template has some examples of what is a use case and what isn't. If you have an actual use case, please open a new issue and describe the use case there. I'm closing this issue, because as stated, solving this issue is actually harmful.