Running while Semantix is closed

This is the point of the Task Manager, and it is the claim most likely to be taken on faith. So here is exactly how it works and exactly when it does not.

What fires your tasks#

Not the app window. Two small background daemons do it, and they divide the job:

• semantix-trig is the clock. For every scheduled task it holds an alarm, and at the scheduled minute it knocks on the door of the other one.
• semantix-tasksd is the hands. It holds the tasks, decides whether a fire is allowed, runs the shell command or the agent, and reports the run to the server.

That separation is the whole trick. The window is where you write a task; the daemons are what run it. They have different lifetimes, and the daemons' is the one that matters at 4am.

Today: they live and die with the window#

When you start Semantix, it looks for each daemon. If one is already running, it adopts it — and never shuts down a daemon it did not start. If none is running, Semantix starts them itself, and stops them again when you quit.

Nothing installs them as a service yet. So on every machine today the second case is the one you're in: the daemons run while the Studio is open, and stop when you close it. A task set for 4am runs at 4am if the Studio is open at 4am, and is recorded as a miss if it isn't.

Three things stop a task from firing#

The Studio is closed. Covered above, and the most common cause by a distance today.

The task is marked project-only. A project task can be set to Only run while this project is open in the studio. A task marked that way will not fire unless that project is open — whatever its trigger, and even by hand. If a task is not firing, check this before anything else.

The server can't be reached. Tasks are a connected service: a run's story must have a durable home on the server before the run exists. So the daemon refuses to fire while the server is away — or while its sign-in has lapsed — and records the refusal as a skipped run with the reason. There is no local cache that fires on its own behalf, no "just this once from memory", and no catch-up storm when the connection comes back. An editor event is its own fourth case: it only exists while the editor is running.

When the server can't be reached#

Semantix does not improvise here, and the design is deliberate enough to be worth stating.

Scheduled tasks do not fire. One thing fires tasks, and if it cannot reach the server, nothing fires.

The miss is recorded, not hidden. A fire the daemon refused appears in the history as skipped — with the reason. You will not find a silent gap where a task should have been.

You are told in advance where possible. The Studio checks the server every thirty seconds, and if it becomes unreachable while a scheduled task is due within the hour, a small notice appears at the bottom right: Upcoming tasks won't run — The server is unreachable, so nothing is scheduled to fire. Missed runs are recorded in history — there is no catch-up — listing each task and when it was due. It offers no button, because there is nothing honest to offer.

When the daemon itself isn't answering, the Task Manager's rail says task manager offline and the page reads Not answering, with a Retry button.

Two runs at once#

A task that fires every minute and takes ninety seconds would otherwise stack runs on top of each other. Each task chooses, under If it's already running: Skip the new run — the default — lets the current run finish and passes on this fire, recorded as skipped overlap; Run both starts the new one anyway.

Skip is also the blunt guard against a task that triggers itself: an agent that runs on File saved and then saves files. Leave it on Skip unless you know you want otherwise.