When a Project Is Busy¶

SLIM will not let two runs work on the same project at the same time. The message you see is a safeguard, not an error.

What the busy signal means¶

Start something while the same Project already has work in flight and SLIM stops you with a dialog headed Project Busy. It opens with There is already a task running for this project. and offers one button, OK.

Nothing has gone wrong, and nothing has been lost. Your click simply did not start anything: the run that was already going is untouched, and the Stage you tried to start is exactly as you left it. Dismiss the dialog and you are back where you were.

The reason for the block is that a Project’s work is cumulative. Each Stage reads what the Stage before it wrote and adds its own results alongside. Two runs going at once would be reading and rewriting the same material at the same time, and neither could be trusted afterwards. Refusing the second start is cheaper than untangling the result.

The reservation covers the whole Project, not the Stage you are on. If Integration Analysis is running, starting Pipeline Generation is blocked too, even though it is a different Stage on a different page. One run at a time, per Project.

It also need not be your run. Everyone on your Team can open the same Project, so the work in flight may have been started by a colleague minutes before you arrived. Where the dialog can tell who started it, it does - see below.

Finding out what is running¶

Read the dialog first. It usually answers the question on the spot. Where SLIM knows the details, the second line names the work, who started it and how long ago, in the form A “integration-analyzer” task is currently running (started by jsmith 5 minutes ago). Please wait until it completes or cancel it before starting a new task.

The name in quotation marks is SLIM’s internal name for the work rather than the Stage name you see in the Project Sidebar, but it is close enough to recognize. If the second line reads Please wait until the other process is finished before starting a new task. instead, the details were not available and you will need to look them up.

To look them up, work through these in order.

The Project Home Page. Its Activity Log streams the extraction as it happens, so this is where to look if you suspect the export is still being unpacked.
The Stage Page you believe is running. A Stage that is working replaces its run button with a Running… pill, and its Activity Log shows the agent’s progress line by line. In Automatic mode the pill reads Automatic Mode Running… instead, and the other controls on the page are grayed out until it finishes.
Background Task History. If the waffle menu in the Header Bar offers Task Queue, it opens a page listing every operation SLIM has run, across every Project. Sort by Completed Datetime and anything still going will be at the recent end with a status of Running. If Task Queue is not in your menu, skip this step - it adds breadth rather than detail, and everything it says about your Project is already in the two Activity Logs above.

One thing not to try: the Project List gives no indication of which Projects are busy. Scanning it will not find the run for you, so go to the Project you were working on and start from its Stage Pages.

If it stays busy¶

Wait first. A run takes minutes rather than seconds, and the larger Stages take considerably longer than that on a big export. A Project that has been busy for a few minutes is not stuck; it is working.

Stop the run if you know it should not continue. Open the Stage Page that is running and use its Stop button. SLIM asks you to confirm, then ends the run and frees the Project immediately, so whatever you were trying to start will go through on the next attempt. In Automatic mode Stop halts the remaining Stages as well, and you can re-run individual Stages afterwards. A Stage you have stopped is marked Stopped rather than failed.

Try the action again if you believe the work has already finished. SLIM re-checks the Project every time you start something, so if nothing is genuinely running any more, the second attempt is simply allowed through.

That last point is important, because a busy Project is never permanently busy:

The reservation is released the moment the work ends, whether it succeeded failed or was stopped.
A run that dies without reporting back - a machine restarted underneath it, for instance - stops holding the Project after about four hours, without anyone having to intervene.

Ask an administrator if none of that helps. Administrators can see which Projects are reserved and can clear a reservation deliberately, which is the right route for a Project that is still refusing to start work when you are confident nothing is running. See Managing Projects.