import/export via cli would cause duplicate key error

[rfehling-mittwald]

Describe the bug !n8n 0.180.0 Tag Change! Importing via cli will cause duplicate key error when the n:m entries in workflows_tags already exists.

n8n import:workflow --separate --input=./assets/processes/
An error occurred while exporting workflows. See log messages for details.
duplicate key value violates unique constraint "PK_a60448a90e51a114e95e2a1[25]([...])b3"

public.workflows_tags
Indexes:
    "PK_a60448a90e51a114e95e2a125b3" PRIMARY KEY, btree ("workflowId", "tagId")

To Reproduce Steps to reproduce the behavior:

1. Export any workflow with some tags
2. Import the workflow via cli

Expected behavior If you import workflow "1231231", the workflows_tags should delete all tag entries of this workflow before inserting new ones. DELETE FROM workflows_tags WHERE "workflowId" = 1231231;

Environment (please complete the following information):

• n8n Version 0.180.0
• Node.js Version 14
• Database system: Postgre

[rfehling-mittwald]

addWorkflowTagIds [...new Set([...(state.workflow.tags || []), ...tags])] <- is wrong https://github.com/n8n-io/n8n/pull/3130/files#diff-763bbe7a668ae49bf87187a1e24ee0efc263663c9441f9254dfa58f7945fbc3dR615

Example: const currentTags = ["tag1", "tag2", "tag3"]; const newTags = ["tag2", "tag3", "tag4"]; console.log([...new Set([...(currentTags|| []), ...newTags])]));

Will return ["tag1", "tag2", "tag3", "tag4"] not the expected result of newTags!

Why using addWorkflowTagIds and not setWorkflowTagIds on an import feature? o_O

But maybe there is an other reason of the duplicate key error (like removing double entries, old existing entries) :shrug:

[wifiuk]

i also get this error in the DB when importing a flow via the GUI

[ivov]

@rfehling-mittwald @wifiuk Thank you for your report.

Unable to reproduce. Tested exporting my current workflows, deleting them from PG and re-importing them. Also tested setting up a fresh PG, creating a new workflow with tags, exporting and re-importing.

Can you please provide more detailed steps to reproduce?

[rfehling-mittwald]

I tried three testcases, all worked:

• docker run -it --rm --name n8n -p 5678:5678 -v ~/.n8n:/home/node/.n8n n8nio/n8n
• docker-compose with postgres with version 14
• docker-compose with postgres with version 10

I guess I have to debug in our current prod system :/ Please let this issue alive, I want to give information when I may find the solution.

[rfehling-mittwald]

Ok, very stupid. We solved the issue.

Our Main n8n was running on 0.181.2, but our gitlab runner which imported the workflows had the n8n version 0.150.0 :roll_eyes:

There was not a bug, just brainlags.

Thanks for the support :)