Supabase Node Dynamic Table Fehler

Supabase Node Dynamische Tabellen-/Feld-Dropdowns schlagen fehl mit „No bridge acquired for this context. Call acquire() first.„

Ich stoße auf ein Problem mit dem nativen Supabase-Node in n8n Cloud, bei dem die Supabase-Anmeldedaten funktionieren und der Node Daten erfolgreich abfragen kann, aber die dynamischen Tabellen- und Feld-Dropdowns nicht geladen werden.

Das Problem scheint sich auf das dynamische Parameterladen von n8n zu beschränken und nicht auf Supabase-Konnektivität, Authentifizierung, RLS oder Tabellenzugriff zu beziehen.

Umgebung

  • n8n Cloud

  • Nativer n8n-nodes-base.supabase-Node

  • Supabase gehostetes Projekt

  • Mit einem neu erstellten serverseitigen Supabase Secret Key

  • Ressource: Row

  • Operation: Get Many

Problem

Die Supabase-Anmeldedaten werden in n8n erfolgreich getestet.

Beim Erstellen eines Supabase-Nodes zeigt das Dropdown Table Name or ID jedoch:

Error fetching options from Supabase

Die Benutzeroberfläche meldet auch:

There was a problem loading the parameter options from server: "[object Object]"

Das gleiche Problem tritt auf, wenn n8n versucht, Feldnamen/Spaltennamen dynamisch zu laden.

Wichtig ist, dass der tatsächliche Supabase-Node funktioniert, wenn die Tabellen- und Feldnamen manuell als Ausdrücke eingegeben werden.

Durchgeführte Tests

  1. Supabase-Anmeldedatentest

Der n8n Supabase-Anmeldedatentest ist erfolgreich.

Ergebnis:

Connection successful

  1. Manueller Tabellenname

Anstatt das fehlerhafte Table Name-Dropdown zu verwenden, habe ich das Feld in den Expression-Modus gewechselt und einen bekannten Tabellennamen manuell eingegeben:

{{ 'example_table' }}

Ich habe dann folgende Daten ausgeführt:

  • Ressource: Row

  • Operation: Get Many

  • Limit: 50

  • Keine Filter

Ergebnis:

Der Supabase-Node hat erfolgreich Zeilen aus der Tabelle zurückgegeben.

  1. Manueller Feldname und Filter

Dann habe ich einen Filter hinzugefügt und einen bekannten Feldnamen manuell als Ausdruck eingegeben:

{{ 'status' }}

Bedingung:

Equals

Wert:

Test

Ergebnis:

Der Supabase-Node hat erfolgreich passende Zeilen zurückgegeben.

Dies bestätigt, dass:

  • Supabase-Authentifizierung funktioniert

  • n8n Supabase erreichen kann

  • Die Tabelle zugänglich ist

  • Die Felder zugänglich sind

  • Filter funktionieren

  • Datenabruf funktioniert

  • Der Supabase-Node selbst erfolgreich ausgeführt werden kann

Der Fehler scheint spezifisch mit dem dynamischen Parameterladen zusammenhängig zu sein.

  1. Direkter Supabase Data API-Test

Ich habe die Supabase REST API auch direkt mit einem n8n HTTP Request-Node getestet.

Anfrage:

GET https://[PROJECT].supabase.co/rest/v1/

Header:

apikey: [REDACTED SERVER-SIDE SECRET]

Authorization: Bearer [REDACTED SERVER-SIDE SECRET]

Die Anfrage ist erfolgreich und Supabase gibt das OpenAPI-Schema zurück, einschließlich Tabellenpfaden und Definitionen.

Supabase scheint also erfolgreich die für die Tabellen- und Spaltenerkennung erforderlichen Metadaten bereitzustellen.

Netzwerkfehler von n8n

Ich habe Chrome DevTools geöffnet und die Anfrage erfasst, die generiert wird, wenn ein brandneuer Supabase-Node versucht, das Table Name-Dropdown zu laden.

Die Anfrage für dynamische Parameteroptionen gibt Folgendes zurück:

HTTP 500

Antwort:

{
  "code": 0,
  "message": "No bridge acquired for this context. Call acquire() first.",
  "level": "warning",
  "tags": {},
  "timestamp": "[REDACTED]",
  "context": {},
  "functionality": "regular",
  "name": "NodeApiError",
  "node": {
    "parameters": {
      "useCustomSchema": false,
      "resource": "row",
      "operation": "getAll",
      "tableId": "",
      "returnAll": false,
      "limit": 50,
      "filterType": "manual",
      "matchType": "anyFilter",
      "filters": {}
    },
    "id": "[REDACTED]",
    "name": "Temp-Node",
    "type": "n8n-nodes-base.supabase",
    "typeVersion": 1,
    "position": [
      0,
      0
    ],
    "credentials": {
      "supabaseApi": {
        "name": "Supabase account"
      }
    }
  },
  "messages": [
    "No bridge acquired for this context. Call acquire() first."
  ],
  "httpCode": null
}

Erwartetes Verhalten

Wenn gültige Supabase-Anmeldedaten ausgewählt sind, sollte das Dropdown Table Name or ID mit den verfügbaren Supabase-Tabellen gefüllt werden.

Nach der Auswahl einer Tabelle sollten die Feld-Dropdowns mit den verfügbaren Spalten gefüllt werden.

Tatsächliches Verhalten

Das Dropdown zeigt:

Error fetching options from Supabase

Die Anfrage für dynamische Parameter gibt HTTP 500 mit Folgendem zurück:

No bridge acquired for this context. Call acquire() first.

Workaround

Der Supabase-Node funktioniert, wenn die Tabellen- und Feld-IDs manuell mit Ausdrücken eingegeben werden.

Zum Beispiel:

Tabelle:

{{ 'example_table' }}

Feld:

{{ 'status' }}

Der Node fragt dann erfolgreich Supabase-Daten ab und filtert diese.

Zusätzliche Hinweise

Ich vermutete ursprünglich RLS oder Supabase-Berechtigungen, aber die obigen Tests scheinen dies auszuschließen.

Derselbe serverseitige Supabase-Schlüssel:

  • besteht den n8n-Anmeldedatentest

  • ruft das Supabase OpenAPI-Schema ab

  • fragt erfolgreich Zeilen über den nativen Supabase-Node ab

  • wendet erfolgreich Filter über den nativen Supabase-Node an

Nur das dynamische Laden von Tabellen-/Feldoptionen schlägt fehl.

Dies scheint ein internes Problem mit dynamischen Parametern/Load-Options von n8n zu sein und nicht ein Supabase-API-Problem.

Ich kann zusätzliche Protokolle, bereinigte Screenshots, Workflow-JSON, n8n Cloud-Versionsinformationen oder andere Diagnosen bereitstellen, falls dies hilfreich ist.

@Chainmaster 1 Frage, auf welcher Version bist du?

Wir nutzen n8n Cloud, Version 1.123.69.

Danke, dass du uns darauf hinweist. Wir haben CAT-4130 als internes Entwickler-Ticket erstellt, um uns damit zu befassen.

@Chainmaster Aktualisiere deine Version auf 2.0, das wurde in 2.19.3 behoben!

Danke, dass du uns Bescheid gesagt hast! Wir wollten die Migration zu 2.x wegen der Breaking Changes vermeiden, aber es klingt, als müssten wir das Migrationstool nutzen

@Chainmaster n8n hat eine Migrationsleitfaden in deinem Admin-Panel, der zeigt, was kaputtgehen wird, damit du im Voraus planen kannst!

Feel free to mark any of the replies as the solution, and have a good day!

Hallo @Chainmaster Willkommen!
Der Patch wurde auf der 1.x-Linie veröffentlicht, daher kannst du bei 1.x bleiben und musst nicht auf 2.x migrieren. n8n hat 1.123.73 mit dem Fix veröffentlicht. Gehe im Cloud-Dashboard zu Manage > Workspace > Updates & maintenance, wähle 1.123.73 im n8n-Version-Dropdown aus und klicke auf Change version. Das löst einen Neustart von ein bis zwei Minuten aus.
Siehe hier: