We’ll have to hear from @nithinj on this topic. The EDD only talks about jobs. It makes me think that job arrays weren’t taken into consideration when writing this EDD.
Prior to 13, the comment of a job array was handled in a very different way than a job. When a job was run the comment would change to either a message saying the job was run or a failed to run message saying the server rejected runjob request. Job arrays were different. The job array comment would remain in flux until the first subjob was run. Once the first subjob was run, the comment would be changed to a message saying the job array has begun. At that point forward the comment would not change.
The scheduler continues with this behavior. It will not change the comment of a job array in state B.
This is all for the exact reason you state. It would be confusing for the job array to say it can’t run when there are running subjobs.
Even if this change is intentional, we now have inconsistent behavior between the scheduler and the server. The scheduler won’t change the comment on a job array once it is in state ‘B’ and expects the comment to remain constant. The current server behavior will change the comment on the job array if the mom rejected one of its subjobs.
We should remove this inconsistency. Either things should go back to the pre-13 behavior, or the scheduler should start changing the job array comment to the reason the current subjob can not run.
I personally think we should revert back to the pre-13 behavior since it is less confusing for our users.