Why an Exstream batch can fail after composition has succeeded

Symptom

A production batch was moved to the failed-job folder even though the main work had completed.

The engine composed the documents. Sorting finished. Archive output and digital delivery completed. A later batch step then failed because it could not open an expected queue report.

The missing report made the engine look guilty. It was not.

An operator used an AI agent to investigate the job. The agent worked read-only across the exact failed-job folder, the deployed PUB package, the approved Design repository objects, the batch configuration, and a narrow window of operational logs.

What the agent checked first

The agent did not begin with a recursive search of the production share. It preserved the exact job identifier and listed the files in that one job folder.

It then separated four outcomes that the batch status had collapsed into one word:

• Exstream engine result;
• batch-orchestrator step result;
• archive transfer result;
• digital-delivery result.

The timeline showed that composition and the outbound steps had completed. The first hard failure appeared later, when a report reader tried to open an XML file for one print queue.

That changed the question from "Why did Exstream fail to produce output?" to "Was this report supposed to exist for this batch?"

Cause

The report belonged to a conditional output queue.

CCMForge Inspect was used to read the deployed PUB package and the corresponding approved objects in the Design repository. The package contained three print queues and three statistic documents. Each statistic document was included only when its own document trigger and queue rule matched at least one post-sort record.

The relevant queue required a classification such as:

PrintOutput = "SV"
and PrintEnabled = true

The agent then counted the classifications in the sorted fixed-width index. The batch contained records for digital delivery, email, and two central-print queues. It contained zero records for SV.

No SV record meant no document in that queue. No document meant no queue output and no XML report. Exstream had behaved correctly.

The batch configuration was wrong because it read the XML report unconditionally:

compose queue output
  -> report may or may not be created
  -> downstream step always reads report
  -> missing-file exception
  -> whole task marked failed

Why the obvious explanations were wrong

The job contained other distracting signals.

One engine phase returned a warning code below the configured stop threshold. That warning did not stop the job. Treating every nonzero return code as fatal would have sent the investigation in the wrong direction.

A separate digital-delivery discrepancy also existed in the same batch. It was real, but the transfer step completed and it was not the exception that marked this task failed.

The exact log order resolved both ambiguities. The report-reader exception immediately preceded the task failure. Earlier phases had already finished.

Resolution

The surrounding batch orchestration must check that a conditional report exists before it tries to read the report.

Any later condition that reads a property from the report needs the same ordering:

fileExists(report) and pageCountIsNonZero

The existence check must run first. If the expression resolver tries to load a report-derived property before confirming the report exists, it can throw a property error even when the Boolean expression appears to guard the step.

Apply the rule to every conditional queue report. Do not create synthetic empty reports and do not lower engine stop thresholds. Both approaches hide the contract error instead of correcting it.

Validation

Test at least these cases:

1. A batch with records for every queue.
2. A batch with no records for one central-print queue.
3. A batch containing digital delivery only.
4. A genuine composition failure that must still stop the job.

For each case, record the engine return code, created queue files, report-reader steps, transfers, and final task state.

Evidence the agent assembled

The agent did not guess from the error message. It connected evidence that normally lives in different places:

• the file that was absent;
• the step that required it;
• the queue rule in the deployed package;
• the approved Design metadata;
• the actual classifications in the sorted index;
• the ordered production log timeline.

The operator could check one bounded conclusion: the queue had no records, the report was optional, and an unguarded reader caused the failure.

See how CCMForge Inspect gives agents structured package and Design evidence.