dsh workflow not triggering: DeepSeek Harness checks

The scheduled DeepSeek Harness workflow was supposed to run at 9pm, and at 9:20 there was still no run record. The first hour of debugging was spent on the canvas, which turned out to be the one place the answer was not.

The DSH plugin workflow that missed its 9pm run

The incident began with a wrong assumption: that a workflow which did not run had failed inside the workflow.

The schedule was configured, the nodes were connected, and the same flow had worked in testing. At 9pm nothing happened. By 9:20 the on-call engineer was editing nodes, which is the most expensive place to start.

A missing run is not a failed run. A failed run leaves a record, an error and usually a stack trace. A missing run means the system never entered the workflow at all, so the nodes were never consulted.

That distinction should have ended the canvas work immediately. Instead it took an hour and two unnecessary edits before anyone looked at the trigger log. The trigger log answers that question in one line.

The postmortem below separates the three assumptions that delayed the fix. Each one pointed at a different layer, and only the last one was close to the truth. The order in which they were tested is part of the lesson.

Assumption one: the DSH plugin trigger must have fired

If no trigger record exists, the workflow never started, and no amount of node editing will change that.

Triggers come in several shapes: event subscriptions, schedules and manual entry points. Each fails differently. An event trigger with a renamed event receives nothing. A schedule with the wrong timezone fires at the wrong hour, or at an hour that already passed. A manual trigger hidden behind a permission never appears.

The first check is whether the trigger layer recorded anything at all. In our incident the schedule was registered, but it was registered in the host's timezone rather than the team's, so 9pm local was 9am elsewhere. The schedule was correct on paper and wrong in practice.

That is a boring answer, and boring answers are exactly what a missing run usually has. Check registration, timezone and disabled windows before touching the flow. Check the zone in the schedule, not the zone on your laptop.

Only after a trigger record exists does the rest of the pipeline become relevant. The trigger is the front door; if it is locked, the rooms inside do not matter. Everything downstream assumes this door opened.

Assumption two: a DSH plugin queue is a symptom, not a cause

A workflow that triggered but never executed is usually waiting behind something else, and the queue is where that something else becomes visible.

Once the trigger fires, the task enters a queue. A stuck prior task, a concurrency limit of one, a stopped executor or a retry storm can all hold it there. From the outside this looks identical to a workflow that never started.

The difference is in the records. A queued task exists and has a timestamp. A missing trigger has nothing. That single fact splits the diagnosis in half.

In our incident there was a second, smaller surprise: an earlier manual run had been stuck for two days and occupied the only slot. The schedule worked; the queue did not move. A single stuck task was enough to hide the healthy trigger behind it.

Clear the queue and trigger once. Immediate execution tells you the workflow is healthy and the backlog was the problem. The backlog was invisible from the canvas but obvious in the task list.

Assumption three: the DeepSeek Harness plugin approval gate was blocking us

A workflow waiting at a confirmation prompt has not failed; it is asking for a decision, and the prompt names the exact action.

Approval gates pause a flow before an out-of-bounds tool call. The prompt shows the tool and its arguments. Reading it is the fastest way to understand what the workflow intended to do.

Two mistakes are common here. The first is treating the pause as an error and restarting the flow, which discards the context. The second is approving without reading, which grants a permission nobody examined.

If the prompt is legitimate, approve or narrow the scope. If it is not, fix the node that produced it rather than the gate that caught it. Either choice is a decision, and the flow will not continue without one.

In the postmortem, the gate was not involved at all, but it had consumed an hour of speculation because nobody had checked whether a task was waiting. A five-second look at the task list would have ruled it out. Ruling a layer out is progress, even when it feels like wasted time.

Reading the DSH plugin evidence in the right order

Evidence has an order: trigger record, queue state, approval prompt, execution log, and only then the workflow definition.

Start with the trigger. If there is no record, stop and fix the trigger. If there is a record, move to the queue. If the task is queued, inspect concurrency and executor state. If it is running, look for an approval prompt. If it completed, the problem is downstream.

Logs make this cheap. Sort by timestamp and look for the first missing event rather than the loudest error. The loudest error is often a consequence of the missing event, not its cause.

A minimal flow and an isolated profile are the two escalation tools. The minimal flow tests configuration; the isolated profile tests the environment. Use one at a time so the result means something.

Write the layer into the incident note. The next person should not have to rediscover which stage was empty. The order is deliberately boring, and it would have ended this incident before the first node was edited.

1. Find the trigger record for the scheduled time.
2. Confirm registration, timezone and disabled windows.
3. Check whether a task exists in the queue.
4. Inspect concurrency, running tasks and executor state.
5. Look for an approval prompt and read its arguments.
6. Compare the failing run with the last successful one.
7. Record the first missing event, not the last error.

The DeepSeek Harness plugin lesson: trace the run, not the canvas

Workflow editors invite editing, but a missing run is an infrastructure question and should be answered outside the editor.

The canvas shows intended behavior. It does not show whether an event arrived, whether a task was enqueued, or whether an executor was alive. Those facts live in logs and lists.

The fix in our incident was a timezone correction and a queue cleanup, neither of which touched the flow. The postmortem's real cost was the hour spent editing nodes that had never been reached. Neither of those changes would have shown up in a node-level review.

Make the trigger record the first screenshot in every incident. It is the cheapest piece of evidence and the one that most often ends the investigation early. It also gives the next incident a starting point instead of a blank page.

The broader lesson for DSH plugins is that orchestration has layers, and a missing run belongs to the layer below the flow. Start there, and the DSH Plugin Hub entry is useful mainly for confirming which workflow plugin and version you are actually running. That is the layer where the investigation should begin next time.