nas-runbooks/common/n8n-baserow-https-interne-econnrefused.md

n8n -> Baserow : ECONNREFUSED sur ecriture (Update/Create/Delete) via https interne

Date : 28/07/2026 Symptome : workflow n8n oTLZguPfPlq9B7El (Moyens Humains Zone Sud Sync) -- toutes les executions horaires en echec depuis plusieurs jours, erreur ECONNREFUSED (NodeApiError: The service refused the connection - perhaps it is offline) systematiquement sur les noeuds Update et Create1 (parfois Delete).

Cause racine : le conteneur Baserow n'expose en interne (reseau Docker n8n, alias baserow.bolbol.tn -> 172.27.0.26) que le port 80 -- aucun TLS ne tourne sur ce chemin interne (le HTTPS public passe par un reverse-proxy externe separe, hors de ce reseau Docker). Les noeuds de lecture (HTTP Request MH a MH3) appelaient deja http://baserow:80/... et fonctionnaient. Les 3 noeuds d'ecriture (Update, Create1, Delete) appelaient https://baserow.bolbol.tn/... (port 443 implicite) -> connexion refusee a chaque appel.

Pourquoi ca a pu passer inapercu : les lectures (pagination GET) reussissaient toujours, seule l'ecriture echouait -- l'erreur remontait bien dans les executions n8n mais sans alerte active dessus.

Diagnostic :

1. GET /api/v1/executions?workflowId=... -> reperer le pattern d'echec recurrent.
2. GET /api/v1/executions/{id}?includeData=true -> lire resultData.runData.<node>[].error.httpCode = ECONNREFUSED.
3. Comparer les url des noeuds en echec vs noeuds qui reussissent dans le meme workflow (GET /api/v1/workflows/{id}).
4. Confirmer cote conteneurs : docker inspect <container> --format '{{json .NetworkSettings.Ports}}' sur Baserow -> seul 80/tcp expose. docker inspect n8n/Baserow --format '{{json .NetworkSettings.Networks}}' -> verifier qu'ils partagent bien le meme reseau Docker et que l'alias baserow.bolbol.tn y est present (Aliases).
5. Test direct depuis le conteneur n8n (docker exec n8n node -e "..." avec http.request, busybox wget ne supporte pas PATCH/DELETE) vers http://baserow.bolbol.tn:80/... -> confirme le fix avant de toucher au workflow.

Fix : remplacer https://baserow.bolbol.tn par http://baserow.bolbol.tn sur les 3 noeuds d'ecriture, coherent avec les noeuds GET existants. Mise a jour via API n8n : PUT /api/v1/workflows/{id} avec {name, nodes, connections, settings, staticData} -- attention : le GET renvoie des cles settings non acceptees en ecriture (ex. timeSavedMode, availableInMCP, binaryMode) -> l'API repond 400 request/body/settings must NOT have additional properties. Ne renvoyer que les cles standard (executionOrder, callerPolicy, etc.).

Regle a retenir : sur le reseau Docker interne n8n, l'alias baserow.bolbol.tn doit toujours etre appele en http:// (port 80). Le https://baserow.bolbol.tn n'est valide que depuis l'exterieur du reseau Docker (ex. context-hub, qui resout le nom via le DNS public/Pi-hole vers le reverse-proxy reel). Ne pas generaliser un scheme sans verifier sur quel reseau tourne le conteneur appelant.

Outillage sans acces direct docker CLI depuis mcp-nas : ssh nas-host puis binaire complet /volume1/@appstore/ContainerManager/usr/bin/docker (pas de docker dans le PATH, pas de sudo NOPASSWD pour Best0f sur docker).