(this is spin-off of existing discussions like #442 and #436)
As clarified by 8b63b58 (for #436), the openEO API allows to restart a finished job.
A job that reached status "finished" however produced (and consumed) quite some resources, valuable to the user:
- job result assets + their metadata
- job logs
- processing costs (credits, ...)
- ...
and is unclear what should happen with these when restarting a job:
- discard existing (meta)data. And if so: when? on restart or when second attempt finished)?
- merge/combine data and metadata in some way? Append (possibly duplicated) assets to result collection or try to be "smart" and skip duplicates?
- what if second run failed? Should final status be "error", and should original results still be available?
- same: what if second run was canceled? What should final status be: "canceled" or fallback to previous status "finished"?
I strongly believe that it is conceptually a bad idea to allow restarting a job that already reached status "finished" because it comes with a lot of additional non-trivial behavior to specify and implement.
Also note that the user does not seem to want to do this anyway:
in the geopyspark implementation and aggregator we (intentionally) ignore a start request on a finished job (just to avoid all the confusion this can cause) and I can't remember any user to question this.
Side-note: I feel the same about restart on a job in "error" or "canceled" state, but I kind of understand the appeal of the ability of restarting a failed or canceled job. However to avoid bike-shedding, I would keep that out of the discussion for now.
(this is spin-off of existing discussions like #442 and #436)
As clarified by 8b63b58 (for #436), the openEO API allows to restart a finished job.
A job that reached status "finished" however produced (and consumed) quite some resources, valuable to the user:
and is unclear what should happen with these when restarting a job:
I strongly believe that it is conceptually a bad idea to allow restarting a job that already reached status "finished" because it comes with a lot of additional non-trivial behavior to specify and implement.
Also note that the user does not seem to want to do this anyway:
in the geopyspark implementation and aggregator we (intentionally) ignore a start request on a finished job (just to avoid all the confusion this can cause) and I can't remember any user to question this.
Side-note: I feel the same about restart on a job in "error" or "canceled" state, but I kind of understand the appeal of the ability of restarting a failed or canceled job. However to avoid bike-shedding, I would keep that out of the discussion for now.