Execustion set to "crashed"

Questions
,
1

Describe the problem/error/question

I run n8n in queue mode and each night i restart all the workers and main processes on the server.
What i found, since several versions, that after the restart some executions will be set to “Error” (“crashed” in the database). It seems like only happening for executions that starts by a time schedule trigger, but i can not say that for sure.
Basically what i see in the UI is that the execution is on “Error” and the run time is exceeded to the time span of the normal start time and the restart of the processes.
Looking into the database directly, i can see that the “stoppedAt” time is the time of the restart and the “status” is set to “crashed” instead.

I “fixed” this by making a backup of the execution_entity table, right before my daily restart and after the restart update the status and stoppedAt columns in the main db with the values from the backup db.

Is this a knowen issue or do i do something wrong? Do i need to do something in particular when i restart the processes?

What is the error message (if any)?

No error message in the workflow!

Please share your workflow

image
image1524×572 85.6 KB

(Select the nodes on your canvas and use the keyboard shortcuts CMD+C/CTRL+C and CMD+V/CTRL+V to copy and paste the workflow.)

Share the output returned by the last node

Information on your n8n setup

  • n8n version: 1.93.0
  • Database (default: SQLite): PostgreSQL
  • n8n EXECUTIONS_PROCESS setting (default: own, main):
  • Running n8n via (Docker, npm, n8n cloud, desktop app): npm
  • Operating system: Ubuntu 22.04.5 LTS
2

This is a side effect of “queue mode,” where:

Executions are coordinated between workers and a main process (bull queue). If processes are restarted in the middle of an active execution and the shutdown or execution status is not handled properly, n8n marks those processes as “crashed” for safety and queue cleanup.

This behavior has been reported before and does not appear to be a bug, but rather a shortcoming in restart management. This is especially critical with Schedule Triggers because: They are automatically launched in the backend and can be left in an intermediate state right at the time of restart.