# 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).