Replies: 2 comments 3 replies
|
This check was introduced in https://github.com/DIRACGrid/DIRAC/pull/5752/files. IIRC (I might be wrong), the reason for introducing this check is that calling commands like |
0 replies
|
Understood... Perhaps we could do one of the following? Either extend the filter in both cases so that it checks for both possible states that may be applied? - res = JobStatus.checkJobStateTransition(jobID, JobStatus.KILLED)
- if res["OK"]:
- jobIDsToKill.append(jobID)
+ can_kill = JobStatus.checkJobStateTransition(jobID, JobStatus.KILLED)["OK"]
+ can_del = JobStatus.checkJobStateTransition(jobID, JobStatus.DELETED)["OK"]
+ if can_kill or can_del:
+ jobIDsToKill.append(jobID)Or remove the client filter and modify Regards, |
3 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Hi,
The stable
DIRAC/src/DIRAC/Interfaces/API/Dirac.pykillJob and deleteJob functions do a transition check to filter the list of jobs for ones that can be killed/deleted respectively. There are a couple of side-effects of doing this:Invalid job specification: []I propose removing the filter from these two functions: There is enough filtering done on the server side to handle all of the possible cases in a sensible way, the extra client-side filtering doesn't seem to add very much (from my perspective), what do people think?
Regards,
Simon
All reactions