Two Steps of One Job Overlap When They Should Not

When two sequential steps of one job run at the same time and you did not ask for overlap, one of two things is true: overlap was configured through lot streaming, or the steps were never linked as sequential and the engine ran them in parallel. EDGEBIC by User Solutions has a specific anomaly check that separates the two cases, so you do not have to guess which one you are looking at.

This post is part of the EDGEBIC troubleshooting guide. It covers what a genuine step-ordering violation looks like, how the engine's dependency graph is supposed to prevent it, and the exact repair.

The Two Reasons Steps Overlap

Overlap on a Gantt is not automatically wrong. A dependency violation is a specific shape, and it is worth naming both cases before you touch anything.

Configured overlap (correct). A downstream step can be told to start before the upstream step finishes. Flow-step overlap sets a start-to-start lag in hours, and a transfer batch size lets the downstream machine begin as soon as the first batch of pieces is ready. Both are lot-streaming tools that compress a job on purpose. When either is present, the overlap you see is the feature working.

Unintended overlap (the bug). Two steps that should run in strict order run at the same time because the engine does not know they are related. It scheduled both from the same earliest start, so their windows collide. Nothing on the routing explains the overlap, and that is the tell.

How the Anomaly Report Tells Them Apart

EDGEBIC's built-in Scheduler Anomaly Report carries a dependency-ordering check. It fires only when a downstream step starts before the upstream step ends and the downstream step carries no flow-step and no transfer batch size. If lot streaming is configured, the overlap is intentional and the check stays silent.

When the check fires, its detail line names the previous step's end time, the next step's start time, and the buffer values on the routing. That is enough to confirm the two steps really are meant to be sequential and to see exactly how far they overlap.

The Mechanism That Should Prevent It

The engine does not read step numbers to decide order. Each routing step carries a next-in-sequence pointer, and the engine builds a dependency graph from those pointers, then sorts the steps so every upstream operation finishes before its downstream one starts. You can read more about this in how EDGEBIC orders operations with dependency graphs.

Two failure modes break the graph:

1. A missing pointer. Step 20 has no next-in-sequence value, so the engine never learns that step 30 depends on it. Both schedule from the job's earliest start and overlap.
2. A wrong pointer. Step 20 points at step 40 instead of step 30, so step 30 is orphaned and treated as independent.

There is a third, quieter case: two steps sharing the same sequence number. The check may not fire, but the order is ambiguous. Keep sequence numbers unique per job so the intended order is never in doubt.

The Repair

Work in this order:

1. Run the anomaly report for the job. Confirm the dependency-ordering check fires and read its detail line for the two step numbers and their times.
2. Open the routing. Check the next-in-sequence pointer on the upstream step. Confirm it points at the step that actually follows it, not a blank and not a downstream skip.
3. Confirm the overlap was not intended. If flow-step or transfer batch size is set and you did not mean to stream, that is your answer instead: clear the one you do not want. See the setup and lot-streaming siblings for the mirror-image case where streaming did not fire.
4. Save and re-run scheduling for that job.
5. Re-run the anomaly report. A clean dependency-ordering check confirms the fix.

A fresh schedule run repairs overlaps caused by transient timing, but a broken pointer survives every run until the routing itself is corrected. That is why step 2 matters most: if the data says the steps are independent, the engine will keep running them in parallel no matter how many times you reschedule.

Why This Is Worth Getting Right

An unintended overlap is not just cosmetic. Downstream operations that start early consume capacity that upstream work still needs, and the promised finish date is built on an impossible sequence. Fixing the sequence link restores an honest schedule. For the broader picture of how order is enforced, how to sequence operations with dependencies walks through building the chain from scratch, and the troubleshooting guide collects the neighboring symptoms.