Eseguire task sul master di n8n

Ho già parlato qui di n8n e di come siano state interessanti le prima 48 ore; nel frattempo è passato qualche mese ed i task sono aumentati fino a raggiungere quota 51. Sono nati task di libreria, cioè subtask che possono essere utilizzarti da altri task per operazioni comuni come interagire con la domotica di casa, ed altri che utilizzano community nodes, quindi componenti di terze parti, per estendere le funzionalità di n8n.

Tra queste estensioni, una piuttosto particolare e parte dell’articolo di oggi è Telepilot, che permette di superare le limitazioni del plugin standard Telegram di n8n. Cosa fa? Mentre il plugin standard può impersonare un bot, Telepilot e la sua libreria Python possono impersonare un client completo e quindi la propria identità su Telegram.

---

Quella che sembra una cattiva idea è una cattiva idea; in generale scriversi un client Telegram significa dare a quel codice il completo accesso a tutte le notifiche ed operazioni su quell’account e devo dire che Telepilot da questo punto di vista è potentissimo se guardiamo i trigger che supporta. Può però essere una buona idea se si vuole accedere a contenuti di gruppi a cui si è iscritti, ma a cui è impedita l’iscrizione di bot. A questo punto possiamo sfruttare la funzionalità per avere – come un’ombra – una automazione n8n che ci segue, legge tutti i messaggi e seleziona quelli di suo interesse, eventualmente rispondendo al posto nostro.

A questo punto mettiamo il caso che vogliate, ad un nuovo messaggio:

fare qualcosa. Facile, si imposta un trigger e si parte! Potete leggervi il messaggio, imporre delle condizioni ed ad un certo punto potreste voler fare una nuova operazione, sempre con il plugin di Telepilot, dentro il vostro workflow.

Lo scrivete, lo testate nel vostro ambiente di sviluppo e funziona: ora ad un nuovo messaggio potete leggerlo, fare le vostre considerazioni ed ad esempio scaricare un file da questo messaggio, tramite un’altra azione del plugin:

Arriva il primo messaggio produttivo e il workflow fallisce. Andate a vedere e… pare che il plugin non risulti loggato anche se approfondendo oltre nei log del worker n8n troverete:

Can't lock file <path>/td.binlog because it is already in use by current program 

E voi vi direte… chi è che lo locka? Pace, scegliete di testare il workflow fallito tamite “Debug in editor” e … funziona perfettamente. Questo succede una, due, tre, dieci volte e non può essere un caso. Usando lslocks risulta che il lock lo detiene il master di n8n (la Web UI) e qui comincia la vera storia.

Master e worker

Da metà 2025 n8n è evoluto e prevede che l’esecuzione dei task sia distribuita. Il master funge da Web UI ed esegue i task interattivamente eseguiti tramite il “test workflow”, i webhook di test o i workflow con manual trigger. Un altro container riceve i webhook produttivi ed infine uno o più container girano come worker e ricevono istruzioni su cosa far girare via Redis. C’è però una cosa che non vi ho raccontato e che non torna, perché ricapitolando:

• Master (la Web UI) riceve le chiamate dei webhook di test, fa girare i manual trigger e le esecuzioni interattive
• Webhook riceve le chiamate dei webhook produttivi
• Worker esegue i task prendendoli da una coda Redis

Ma chi avvia i task “non webhook” e li accoda in Redis, ad esempio i task schedulati, i trigger applicativi (Jira, Telegram ufficiale, Telegram Telepilot, Kafka, IMAP e così via)? Ecco, lo fa il Master che quindi pur non facendo girare i task, è comunque una parte fondamentale della vostra installazione; se si ferma la Web UI, un task schedulato non partirà mai.

E qui veniamo al dramma del lock: il Master detiene il lock su quel file perché per tutta la sua vita fa girare il plugin Telepilot in attesa di messaggi. Quando il messaggio viene ricevuto, questo viene inserito con tutti i suoi dati di input in Redis e schedulato per girare su un worker… che condivide il filesystem del master e non può leggersi il database td.binlog.

E quindi?

Far girare i task sul master

Una volta attivato il QUEUE mode in n8n non c’è alcun modo per delegare una singola operazione, o un intero workflow, al master. L’unico modo in cui un task può essere fatto eseguire sul master è eseguirlo interattivamente via Web UI, in modalità “debug”. Se ve lo state chiedendo, e Google Gemini ad esempio se lo è chiesto, non esiste una API per avviare un workflow interattivamente, perché le API documentate non sono state pensate a questo scopo. E’ anche vero però che la GUI chiama una API, seppur non quella ufficiale, per avviare i task in maniera interattiva, ma come?

Beh intanto richiede una login interattiva, mentre le API di N8N in /api/v1 usano un token, e poi richiedono una chiamata http://n8n/rest/workflows/<workflow-id>/run abbastanza articolata; la chiamata infatti contiene:

• l’intero workflow, in pratica il test (essendo potenzialmente il task ancora non salvato) invia il contenuto del progetto via POST
• il nome del trigger da avviare
• l’eventuale contenuto dei dati di input

Interessante no? Ma quindi come possiamo fare?

Possiamo farci un subworkflow “di libreria” che non faccia altro che:

• loggarsi tramite le credenziali di accesso alla Web UI (si, lo so, in una instanza self-hosted significa le proprie credenziali di accesso) e salvare il cookie ritornato
• sfruttare le API di n8n per scaricarvi il contenuto del workflow di interesse
• invocare la chiamata di test con i parametri ricevuti in input

In pratica quindi non dovrete fare un subworkflow dedicato al singolo task (anche se io ho fatto così, perchè la mia esigenza al momento è molto puntuale) ma potete fare una libreria generica che una volta chiamata con i parametri di vostra scelta e il workflowid, lo scarichi, lo configuri e lo esegua. Un esempio pratico:

Per prima cosa vi loggate, potete creare una credential e i parametri in input sono

{"emailOrLdapLoginId":"<username>","password":"<password>"}

poi vi scaricate il workflow con il node “n8n API” ufficiale:

ed infine lo eseguite:

e come body JSON:

{
  "workflowData": {
    "name": "{{ $json.name }}",
    "active": true,
    "id": "{{ $json.id }}",
    "nodes": {{ JSON.stringify($json.nodes) }},
    "connections": {{ JSON.stringify($json.connections) }},
    "pinData" : {
      "start.remote": [
        {"json": 
          {{ JSON.stringify($('start.local').item.json) }}
        }
      ]
    }
  },
  "triggerToStartFrom": {
    "name": "start.remote"
  }
}

Tutto molto parametrico se non il nome del trigger da invocare, che potete tranquillamente far passare sempre in input nel nodo di trigger. In questa maniera questo task viene esplicitamente eseguito come “test run” sul master, aggirando le limitazioni imposte dalla libreria TD di Telegram.

Questo post è disponibile anche in: English