غير قادر على الاتصال بـ Supabase من سير عمل n8n (العمل من جهاز MAC المحلي)

صِف المشكلة/الخطأ/السؤال

لقد قمت بتثبيت n8n على جهاز Mac الخاص بي (Docker) وحاولت الاتصال بـ Supabase RAG الخاص بي، لكن الاتصال فشل. حسبما هو مطلوب في “Host”، نسخت من Supabase (Project Settings >> Data API) وهو يبدو مثل “https://bmactddfrfrmvegzlrvt.supabase.co/rest/v1/” وفي “Service Node Secret” استخدمت مفاتيح API من Settings >> API Keys (Supabase) والمفتاح يبدو مثل “sb_secret_x7O7Ea-PvGcWd_0MNMdgdQ_tsE7IkIH”. هنا استخدمت المفاتيح السرية وليس المفاتيح القابلة للنشر. ومع ذلك، أتلقى “لم يتمكن من الاتصال بهذه الإعدادات. المزيد من التفاصيل”. عندما نقرت على رابط المزيد من التفاصيل حصلت على “المورد الذي تطلبه لم يتم العثور عليه”.

ما هي رسالة الخطأ (إن وجدت)؟

يرجى مشاركة سير عملك

(اختر العُقد على لوحتك واستخدم اختصارات لوحة المفاتيح CMD+C/CTRL+C و CMD+V/CTRL+V لنسخ ولصق سير العمل.)

شارك الإخراج المُرجع من قبل العُقدة الأخيرة

معلومات حول إعداد n8n الخاص بك

  • إصدار n8n:
  • قاعدة البيانات (الافتراضي: SQLite):
  • إعداد EXECUTIONS_PROCESS في n8n (الافتراضي: own, main):
  • تشغيل n8n عبر (Docker, npm, n8n cloud, تطبيق سطح المكتب):
  • نظام التشغيل:

مرحباً @subroto، أهلاً وسهلاً!

الخطأ 404 يأتي من حقل Host الخاص بك. n8n يضيف جزء /rest/v1/ بنفسه، لذا عندما تضمنه يتضاعف المسار وتعيد Supabase “resource not found.” عيّن Host على عنوان المشروع الأساسي فقط، مثل https://your-project.supabase.co بدون أي شيء بعد .co، وستنجح الاتصال.

وأيضاً، وهذا مهم: غيّر مفتاح السر الخاص بك. لقد لصقت مفتاح sb_secret مباشر في منشورك، لذا يمكن لأي شخص يقرأ هذا أن يستخدمه. أنشئ واحداً جديداً في Supabase واستبدله.

أهلا وسهلا! لا تتردد في تحديد أحد الردود كحل والاستمتع بيومك!

شكراً لك كثيراً. جربت اقتراحك وحققت النجاح.
شكراً والتقديرات،

قمت بالتبديل إلى n8n المستضاف ذاتيًا (Hostinger) وجربت الخطوات. (أ) على Supabase، قمت بحذف المشروع وإعادة إنشاء مشروع جديد (ب) أنشأت جدول “documents” وقمت بتشغيل ‘select schemaname from pg_tables where tablename = ‘documents’ limit 100;’ >> والذي أرجع ‘public’ (ج) قمت بإعداد بيانات الاعتماد من n8n (لـ Supabase Vector Store) بنجاح. (د) تأكدت من تفعيل الامتداد للمتجهات.
ومع ذلك، لا يزال اسم الجدول لا يظهر، كنت أتوقع العثور على ‘documents’ (ما زلت أتلقى 404). شكرًا

@subroto حسناً، تم حفظ بيانات الاعتماد بنجاح وبالتالي المضيف صحيح هذه المرة، خطأ 404 الآن في طبقة الجداول وليس الاتصال. سببان:

  1. ذاكرة تخزين مؤقت لمخطط PostgREST. Data API في Supabase يخزن المخطط مؤقتاً، لذا يحدث 404 للجدول الذي تم إنشاؤه للتو حتى يتم إعادة تحميله. شغّل في محرر SQL: NOTIFY pgrst, ‘reload schema’; (أو انتظر دقيقة / أعد تشغيل المشروع)، هذا عادة ما يجعل المستندات تظهر.

  2. جدول عادي غير كافٍ. متجر Vector يحتاج إلى مستندات تحتوي على أعمدة id و content و metadata و embedding vector(N) بالإضافة إلى دالة match_documents. شغّل SQL من بدء التشغيل السريع لمتجر vector في Supabase (مرتبط في توثيق العقدة)، وعيّن Query Name إلى match_documents، وطابق بُعد المتجه مع نموذج التضمين الخاص بك (1536 لـ OpenAI صغير/ada).

أيضاً، العقدة تتجاهل اسم جدول مخصص وتستخدم دائماً documents، لذا احتفظ به باسم محدد بالضبط.

مرحباً @subroto، فقط لإضافة ما قاله @achamm حول إعداد Vector Store.

عند تشغيل SQL quickstart الخاص بـ Supabase، تأكد من أن بُعد الموجه يطابق نموذج التضمين بدقة. عدم التطابق، مثل استخدام vector(1536) لكن نموذجك ينتج vector(3072)، سيفشل بصمت أو سيعيد 404 عند الإدراج. تحقق من بُعد الإخراج الخاص بنموذجك قبل تشغيل سكريبت الإعداد.

من الجدير أيضاً التأكد: يجب أن تكون دالة match_documents موجودة في المخطط العام (public schema)، وإذا انتهت في مخطط مختلف، فإن n8n لن يجدها حتى لو كان الجدول صحيحاً.

بمجرد وضع هذه الأشياء في مكانها، قم بتنفيذ NOTIFY pgrst, ‘reload schema’; بسرعة كما اقترح achamm وستكون مستعداً للانطلاق!

شكراً!
سأتحقق من ذلك.