We have certain job types that are submitted with a single task, which then generates a new set of tasks and uses RepositoryUtils.SetJobFrameRange to change its own frame range in place, triggering an automatic re-queue of task 0. This works fine, except that no job report is ever created for that first run of task 0, so debugging it is a pain.

Is there a way to force a report with the log of the first iteration of the task to be created in these situations, like it is when a task is re-queued from the monitor?

The first task generates a new job? This may be causing more trouble than I'm not expecting, but why not just create that other job with an event script? That would get logged in the job reports as normal.

I think the problem is that the task is killing itself. Requeuing a running task should throw away the current job report normally.

No. The first task runs some code that generates new work to do, and then changes the frame range of its own job based on the amount of work that was generated, which triggers a re-queue. In other words, it's a one-time operation, and fundamentally changes the underlying job (ours, not Deadline's).

When a user re-queues a running task, it creates a "Requeue" report for the job that includes the task log up to the point it gets interrupted. I would like to do the same thing programmatically.

We created a function to add requeue reports on top of the older one... Hmm. Let me play around with this a bit today, there may be something up with this.

Update:

It looks like I only get a requeue report when the job is rendering. I'm thinking we should probably make this happen anytime we call the queue *and* we should probably adjust where it claims the queue happened, because this wasn't from the Monitor:

eamsler wrote:It looks like I only get a requeue report when the job is rendering. I'm thinking we should probably make this happen anytime we call the queue *and* we should probably adjust where it claims the queue happened, because this wasn't from the Monitor:

I'm not sure what else I can say... I'm definitely not getting these reports, in spite of the fact that SetJobFrameRange is being called while the job is rendering.

Here's the whole picture:

The job is initially submitted with a single frame (1).

That one frame does some checks and then may or may not discover that it needs to run many tasks instead of just one.

If it does, it triggers a web service script that will set its own job's frame range to 1-N (where N is the number of tasks it needs), and then goes to sleep until its task is requeued.