AE2 autocrafting: the job sits on Scheduled and never crafts

AE2 will not tell you which one it is

There is no message for any of this, and one screen actively misleads.

What AE2 does say:

• The ME Pattern Provider's own screen shows Crafting is locked or Crafting is unlocked, and hovering names the reason: "Locked by redstone signal", "Locked by lack of redstone signal", "Waiting for redstone pulse to unlock", "Waiting for %s (%d) to unlock". That is the only stall AE2 labels.

What it never says anything about:

• a provider still holding items it could not fit into the machine;

• no provider left on the grid for that pattern;

• not enough energy to push;

• blocking mode holding the push;

• inputs missing from the CPU because an earlier output never came back;

• the operations budget.

The one warning on the Crafting Status screen cannot appear during a stall. Can't Store Contents! is only set when the CPU has no job and cannot empty its inventory into the network. If you are stalled, you have a job, so you will never see it.

The ETA is the stall, not a second bug. The time at the top is elapsed time divided by how much is done, multiplied by what is left. While a job is stalled the elapsed time climbs and the completed count does not, so the figure grows without limit. "245767 hours" is that division, not a broken timer. The yellow box is the Scheduled colour, shown when coloured crafting status is on in the client config.

↑ Back to the steps

Step 1: is the job suspended?

The Crafting Status screen has a Suspend and Resume button. A suspended job looks exactly like a stalled one: everything sits in Scheduled and nothing moves.

It is one click to rule out. Do it first.

↑ Back to the steps

Step 2: read the columns

1. Anything in Crafting? Go to Step 3.

2. Nothing in Crafting, everything in Scheduled? Go to Step 4.

3. Are your crafters only Molecular Assemblers, with no machine from another mod in this recipe? Read Assembler-only setups as well, whichever of the two you have. That case has its own cause.

↑ Back to the steps

Step 3: something is stuck in Crafting

An output that AE2 is waiting for never arrived, and nothing will ever reconcile that. The count in Crafting comes from the pattern's declared outputs, added when the push succeeded. It only comes down when matching items enter the ME network. Fewer items than the pattern claims, a different item, or the output taken by something else, and the number stands forever.

Check these, in order:

1. Did the machine get part of the batch and stop? This is the commonest shape in the reports: "8 redstone dust arrive, the remaining 4 never do", "it sends one request with 3 items when it clearly needs 4", "it always gets stuck on the very last one".

   Before pushing, the provider only checks that each input can be inserted at all, not that the whole amount fits, and it checks each input on its own. The real push then inserts what it can, and the remainder waits in the provider. A machine that needs the whole batch in one go sits there holding part of it.

   The direct counter is blocking mode on that provider. With it on, the provider will not push to a side while the machine there still holds any of the pattern's inputs, so it will not top up a machine that is already part-way through your batch.

   It does not change the check that strands the remainder in the first place, so a push into an empty machine can still leave part of a batch behind. If that happens with blocking mode on, you have not set it up wrong.

2. Does the machine return exactly what the pattern says? If it gives fewer items, or a different item, the count never comes down.

3. Is anything else taking the output? A hopper, a pipe, an item mover such as SFM or Modular Routers, or a storage bus on another network, can take the output before it reaches the ME network. Then it never counts.

4. Is a second provider or an ME Interface next to that machine? One player's own answer was exactly that: an advanced pattern provider next to the machine was swallowing the items instead of the machine above.

5. Still nothing? Try cancel and re-request. It genuinely fixes this half. If you have already done that once and the same stall came back, this page does not explain it: see Unresolved.

↑ Back to the steps

Step 4: everything is in Scheduled and nothing is in Crafting

Every provider that holds that pattern is refusing the push. Walk them, in this order:

1. Is the provider locked? Its screen says Crafting is locked with the reason on hover. One of the four lock modes is "Until primary crafting result is returned", which never unlocks if that result never comes back.

2. Is the provider still holding items it could not fit into the machine? This one is not possible if that provider's only neighbours are Molecular Assemblers: see Assembler-only setups. Otherwise, while it is holding them, it is busy and every pattern on it stays Scheduled. It retries every tick, removing items only as the machine takes them. This one survives a restart: that list is saved with the block, along with the side it was pushing to. So breaking or filling the machine in front of a provider mid-craft leaves that provider busy for good, and the sharpest test is a machine in front of a provider that is full, gone, or refusing items.

3. Is blocking mode holding it? The counter to the Step 3 fault is also a way to stall: a provider with blocking mode on will not push while the machine still holds any of the pattern's inputs.

4. Is the provider still on the same grid as the CPU? Providers are grid-scoped. A broken cable, a lost channel or a chunk that unloaded takes the provider out of the list, and the pattern stays Scheduled for good.

5. Which side is it pushing to? A provider will not push through a side facing another Pattern Provider or an ME Interface on the same grid. Those sides are skipped.

6. Power. A pushing provider needs energy for the push, and a bigger pattern costs more. A browning-out grid stalls pushes with no message.

7. None of these? Try cancel and re-request, and read what it does not fix before you conclude anything from the result. If you have already been round these six checks and cancelled once, this page does not explain your stall: see Unresolved.

↑ Back to the steps

Assembler-only setups

If your crafters are Molecular Assemblers and no other machine is in the recipe, the provider cannot be holding leftover items. A pattern going to an assembler is handed over whole: the assembler takes all of it or refuses, so nothing is ever left behind in the provider.

What can stall one instead:

1. An assembler refuses a new pattern while it still holds one.

2. It only clears that state by pushing its finished output back to the side the pattern came from.

3. If that push keeps failing, because the provider is gone or its return inventory cannot drain into the network, the output stays in the assembler and it is occupied forever. Every pattern for it stays in Scheduled.

So look at what is next to the assembler, and whether the provider that fed it is still there and can take the output back.

Players describe the visible end of this as items stuck inside their assemblers, sometimes stacked oddly in one slot, with the queue paused indefinitely.

↑ Back to the steps

What cancel and re-request does and does not fix

It fixes an output that never came back. Cancelling drops the job, clears what the CPU was waiting for, and returns the CPU's inventory to the network. A fresh request then plans against what is actually in storage now, including the intermediates that did come back.

It does not fix a provider that is still holding items it could not insert. The new job stalls in the same place, for the same reason.

That makes it a useful test. If you cancel, re-request, and the job stalls at the same point, the fault is in your build rather than in the job. Where to go next depends on what your screen shows:

• Something is in Crafting again: back to Step 3, items 1 to 4, which is where the output is being lost.

• Everything is in Scheduled and Crafting is empty: back to Step 4, checks 1 to 6.

• You have already worked through those checks once: this page does not explain your stall. See Unresolved.

↑ Back to the steps

What restarting does

The provider's held items, its lock state and what it is waiting for are all saved with the world, so a restart does not clear a stuck provider by itself.

↑ Back to the steps

What the reports point at

54 stalled posts were read and coded. Of those, 21 are in packs ForgeBase covers, and those are on the same AE2 build this pack ships. 8 are in packs we do not cover, including one the poster says is Minecraft 1.12.2, which is not version evidence for anything here. The other 25 name no pack at all.

This is a consistent direction, not a measurement. It is enough to order the steps on this page, and not enough to name a cause. The page's order follows it.

• An output that never came back is the best-supported. Six players fixed their stall by cancelling and re-requesting, changing nothing physical.

• The assembler case is next. Eleven posts are AE2's own crafters only, where a provider cannot be holding leftovers.

• A provider still holding items is third, but it has the sharpest test and it is the only one that survives a restart.

Weighted out as the common cause, with reasons:

• Lock modes. The only lock string players quote is Crafting is unlocked, which is what you see when the provider is not locked. They checked and ruled it out themselves.

• Network topology and hardware. Four players rebuilt hardware and none of them fixed it. We do not know whether all four replaced the provider specifically rather than the CPU, controller or cables, so this is weaker than it looks.

• Power or channel loss. A stall from those clears itself when power returns, and cancelling would not have been the fix.

Cannot be weighed either way: co-processors, subnets, P2P tunnels, Quantum Rings and the CPU-inactive path. Nobody mentioned them, which is not the same as their being absent.

↑ Back to the steps