Error A prior build is still executing on Cron job

When running a cron job, if there is an unfinished build triggered by the current commit, there is the following error: A prior build is still executing. under the requests page.
Is there anything I could do or is this expected?

Yes, it is expected. Do you have reasons to believe that this was an error?

yes, I have jobs behaving differently on Cron than on regular pushes.
If by mis-chance, the cron is occurring just after a commit, the job won’t be run (my jobs are in the range of 30-90min, so it is quite probable).
Do you see a way to circumvent this?

Are you saying that when you push to a branch that has a cron job set up while the cron job is still executing, the build request is rejected? Or, are you trying to execute another cron job while one is already running? Which repo is behaving this way, and when did it happen? (The requests page URL is sufficient.)

it’s a bit different, I am trying to run a cron job while the push job (of the last commit) is still running
commit 03fcded on branch release-3_6, cron ran at 17:18 GMT+1

The latest cron request

was rejected because this one is still running The cron jobs and regular push jobs are evaluated independently whether or not they should be accepted.

The shortest time period you can set up cron jobs is “daily” and this should be enough to have them not overlap to avoid this error message.

Thanks a lot for digging in.
I am just cancelling and recreating the crons to test it works as expected.
So you’re saying the issue is just because I need to let more time between two cron jobs and that it has nothing to do with the fact that a job is currently running with the same commit?

PS: Ijust tested again on master, previous cron job was 2h ago, but there is a push job running and I do get the error:

I misspoke here. Currently all jobs on the branch are considered. So, prevented your cron job from running.

(Optionally, you can configure your cron job to “Always run.”)

Ah, ok, so pretty much nothing to do.
It’s already configured as “always run”.
Maybe, it would be nice if the job could be queued instead of canceled (but probably not easily done)?
thanks again for digging in.