Workflow editor not responding

Describe the issue/error/question

We have deployed n8n in AKS, and when trying to edit workflows we can’t select nodes or open them. One thing we suspect is that n8n needs access to some external resource, does it for example need to phone home or similar? The environment is heavily locked down.

What is the error message (if any)?

No error message, nothing in the browser console or in the n8n logs.

Share the output returned by the last node

Information on your n8n setup

  • n8n version: 0.211.1
  • Database you’re using (default: SQLite): PostgreSql
  • Running n8n with the execution process [own(default), main]: Tried both own and main
  • Running n8n via [Docker, npm, n8n.cloud, desktop app]: Docker/kubernetes

Hi @nanderss, welcome to the community :tada:

I am sorry to hear you’re having trouble. A similar question this came up recently over here:

Are you encountering similar symptoms? If so, you might indeed need to disable all “phone home” functionality as described over in the other thread. I’ve also listed the relevant variables separately here on my blog for future reference.

Hi @MutedJam,

no, the symptoms are not the same. We have now opened up network access, but the problem persists. We can’t edit workflows, the nodes do not respond to clicks. The same workflows running on a local machine with the same version of n8n works without any problems.

So in this case I have no clue tbh. We had issues with misconfigured proxy servers in the past, but they wouldn’t typically prevent you from opening node details for example.

Anything other than errors (e.g. warnings) in the browser console when trying to click on any of the non-working UI elements, any failed network requests?

No, nothing. This is really weird, we have no idea what this is.

A possible theory: We recently upgraded n8n from a 0.200 or something, and it might be that this problem only affects workflows that were originally created on an older version. Is this a known issue @MutedJam ?

It seems like copy/paste to a fresh workflow removes the issue.

Well, this sure sounds odd :frowning:

I am very glad to hear you found a workaround though.

Hi @nanderss, would you be able to export and one of the problematic workflows with me? I’ve added this to our bug tracker for a closer look but wasn’t able to reproduce the problem so far. Seeing there is a similar report, I think this should definitely be looked at in more detail though.

Thank you so much!