Activating a workflow from the API results in timeout and workflow staying Inactive

[theo-basty]

Describe the bug I'm trying to use n8n nodes to create and activate workflows. I'm able to create a workflow wothout any issues, but i'm unable to activate it. Every time i try to activate a workflow through the API (with n8n nodes as well as with Insomnia) it ends up with a timeout from the n8n server. During my tests, i was able to confirm that the deactivation worked fine, and that the activation worked fine IF the workflow was already active. Also, it fails to activate with every workflows.

To Reproduce Steps to reproduce the behavior:

1. Create a Workflow
2. Use an API client to call the /workflows/{id}/activate endpoint using an API token

Expected behavior The server should answer and activate the workflow, as documented for this API endpoint

Environment (please complete the following information):

• OS: Unknown, Docker
• n8n Version : 1.7.1 (public docker image)
• Node.js Version : As per the docker public image
• Database system : SQLite
• Operation mode : main

Additional context I don't know what else could impact this

[Joffcom]

Hey @theo-basty,

Thanks for taking the time to report this, I was just looking at some of my workflows and I have a workflow that deactivates a workflow at 4pm every weekday and activates it at 8am and it doesn't appear to have any issues.

I have done a couple of quick tests using Insomnia and the n8n node on other workflows as well and for some reason I can't reproduce this.

Can you share your configuration for n8n and compose file if you are using one and maybe a workflow that has the issue so I can test that here.

[theo-basty]

Hey ! Thanks for your answer !

I can provide you the docker compose and the workflows that causes errors n8n.zip

The main issue appears in TaskAssignmentManager, which creates a new workflow based on taskflow_template (using its id to get it from the API) and tries to activate it. A MQTT Broker would be used to trigger the first workflow and to communicate with other softwares and the newly created workflow.

Also, I checked the logs (either the browser console and the n8n container) and i don't see anything weird or any errors that would indicate that something is going wrong.

[jkirkpatrick]

I'm running into the same problem backing up and restoring workflows in a container using the exact same environment as the original issue:

I have 4 or 5 deactivated workflows when I run n8n export:workflow. Later I import those workflows:

n8n import:workflow --separate --input=/path/to/backups/

Importing 17 workflows...
Deactivating workflow "X" during import, remember to activate it later.
Deactivating workflow "XX" during import, remember to activate it later.
Deactivating workflow "XXX" during import, remember to activate it later.
...
An error occurred while importing workflows. See log messages for details.
SQLITE_CONSTRAINT: NOT NULL constraint failed: workflow_entity.active

Going back and disabling ALL of the workflows before export will immediately fail when importing them:

n8n import:workflow --separate --input=/path/to/backups/

An error occurred while importing workflows. See log messages for details.
SQLITE_CONSTRAINT: NOT NULL constraint failed: workflow_entity.active

This does not show any messages other than above.

Activating all of them before export results in behavior identical to partial / some disabled and some enabled.

[Joffcom]

@jkirkpatrick that looks there could be an issue with the database but I will test that as well, can you confirm which version you are on?

[jkirkpatrick]

@Jeffcom - Not an issue with the DB. Works fine with 1.6.1; issue occurs with imports 1.8.x only. (even if the export was made with 1.8.1 and imported into 1.6.1). There's definitely something messed up with the active state.

[Joffcom]

Hey @jkirkpatrick so is the issue exporting from 1.8 and importing into 1.6, 1.6 to 1.8 or just 1.8 to 1.8? Are these webhook triggered workflows or scheduled?

[jkirkpatrick]

Can not import after 1.6 using CLI - this may be a separate issue but it's definitely related to active state and only happens on versions after 1.6

[FranciscoKnebel]

My use case was exporting v0 workflows and importing it to v1. Downgrading from v1.16 to v1.15.2, I was able to import the workflows just fine.