Bug #6439
open
[Workbench] Copying jobs causes "SubmitIdReused" error if submit_id is not null
Added by Tom Clegg almost 10 years ago.
Updated almost 4 years ago.
Description
While copying jobs and pipelines into a project:
Started POST "/actions" for x.x.x.x at 2015-06-26 21:01:06 +0000
Processing by ActionsController#post as JSON
Parameters: {"uuid"=>"...", "copy_selections_into_project"=>"true", "selection_param"=>"uuid", "success"=>"page-refresh", "selection"=>[...]}
#<ArvadosApiClient::ApiErrorResponseException: #<Job::SubmitIdReused: Job::SubmitIdReused> [API: 422]>
Submit_id is supposed to be NULL or unique, but of course it isn't unique if you make a copy of a job with a non-NULL submit_id.
The submit_id should be set to null when copying a job.
It's hard to make "copy job" work well in the general case. Even if we restrict it to copying Completed/Failed jobs, it would be a bit strange in that the original would be an assertion by the system that the job ran that way, while the copy would be an assertion by the user that the job ran that way. (This is the sort of thing we're fixing by splitting "job" into distinct "job request" and "job" (or "container request" and "container") objects in Crunch2.)
I'm guessing the motive for copying jobs here is to give permission to view the details about a completed job ("copy the things I want to share into a shared project"). In that case, the workaround might be simply "don't copy the jobs":
- Copy the pipeline instances into the project, but not the individual jobs.
- Permission to see the job records won't change, but permission to see the pipeline instances will -- and they have a cached copy of the job information.
- Copy the relevant outputs and logs into the project. (You'd have to do this anyway even if copying jobs worked.)
- Target version changed from Bug Triage to Arvados Future Sprints
- Target version deleted (
Arvados Future Sprints)
Also available in: Atom
PDF
Updated by 
Updated by 
Updated by