UX of deleted job results

[m-mohr]

I have some older job results in my batch job overview.
In the Web Editor, it says the results are not available any longer. This is generally fine, we discussed this before.
The UX is a bit weird though:

(1) The batch job result is still "finished" although no results can be requested.
Should the job status change to created once the results get deleted?
I think that would make a little more sense to me.

(2) Also, as the job results have been deleted and the UDP is still stored, I tried to queue the job again to get the results computed again. Unfortunately, if I queue again that seems to not initiate any actions. I have to create a new job from the metadata. Why?

[soxofaan]

I think this is related to earlier discussions like

• response on starting a job that is already queued/running/finished openeo-api#442

Currently, in the "VITO" backend you can only start a job from status created or cancelled:

openeo-python-driver/openeo_driver/views.py

Lines 966 to 971 in ad73911

	if job_info.status in {JOB_STATUS.CREATED, JOB_STATUS.CANCELED}:
	_log.info(f"`POST /jobs/{job_id}/results`: starting job (from status {job_info.status}")
	with ExtraLoggingFilter.with_extra_logging(job_id=job_id, user_id=user.user_id):
	backend_implementation.batch_jobs.start_job(job_id=job_id, user=user)
	else:
	_log.info(f"`POST /jobs/{job_id}/results`: not (re)starting job (status {job_info.status}")

once a job reaches status finished or error, it's final, you can not restart that particular job.

The batch job result is still "finished" although no results can be requested.
Should the job status change to created once the results get deleted?
I think that would make a little more sense to me.

I disagree here, I don't think it's a good idea to flip a job from "finished" to "created" automatically from the backend side. Note that even if the results are deleted for some reason, there is still job metadata that can be relevant for the user: its final status, processing costs, usage stats, execution logs. All that should not be discarded automatically.

I have to create a new job from the metadata. Why?

In typical Python/R/... workflow contexts that's actually the most straightforward way to create jobs: run your workflow script again to create (and start) a new job. I've never heard a Python client user ask about how to restart an existing job after it finished/failed job, just creating+starting a new job is a lot more natural. The JS client or webeditor could implement this approach to with some kind of "clone this job to new job" button.

[m-mohr]

once a job reaches status finished or error, it's final, you can not restart that particular job.

Fair enough. Nevertheless, hitting the endpoint to restart the job should result in an error then. Something like: "Job can't be restarted. Please create a new one." Succeeding without any action is pretty confusing.

I disagree here, I don't think it's a good idea to flip a job from "finished" to "created" automatically from the backend side. Note that even if the results are deleted for some reason, there is still job metadata that can be relevant for the user: its final status, processing costs, usage stats, execution logs. All that should not be discarded automatically.

Fair enough. The most common reasons seems to be the auto-deletion after x months or so. I face that quite a lot and there's absolutely no indication whether jobs still have results or not. Maybe a new job status would make sense? Or a timestamp, see Open-EO/openeo-api#542 Any indication would help to indicate the "special" status in the UI. (By the way, I'd think a delete of the result is an update, but the updated doesn't reflect the change to the job.)

In typical Python/R/... workflow contexts that's actually the most straightforward way to create jobs: run your workflow script again to create (and start) a new job.

Yeah, that's a different way of executing it. Pretty wasteful though. That's one of the reasons why you end up with pagination. ;-)

The JS client or webeditor could implement this approach to with some kind of "clone this job to new job" button.

We could probably add a "queue as new job" button, but it's already pretty easy to duplicate jobs: "edit process" -> "create Batch Job". But that needs to be explained to users, that's nothing you'd just intuitively understand...

Also, I'd only want to show it if the server doesn't support restart, which we don't know. Needs an API flag again.