جداول Google - خطأ في المطابقة التلقائية للأسماء

أسئلة
1

العنوان: عقدة Google Sheets (Auto-Map، typeVersion 3) تكتب القيم في عمود واحد بانحراف بعد الترقية إلى 2.22.5

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

بعد ترقية n8n من إصدار أقدم (حوالي 10 إصدارات سابقة) إلى 2.22.5، بدأت عقد Google Sheets التي تستخدم “Auto-Map Input Data to Columns” تكتب القيم إلى الأعمدة الخاطئة على عمليات Append و Update. لم يتم تغيير أي عقدة — فهي لا تزال typeVersion 3 (الأحدث هو 4.7). المتغير الوحيد كان إصدار n8n.

عدم المحاذاة عبارة عن انزياح متسق بمقدار عمود واحد نحو اليسار يبدأ عبر صف الصفوف:

  • الكتلة الأولى من الأعمدة تتطابق بشكل صحيح.

  • من عمود معين فما بعده، كل قيمة تستقر في خلية واحدة إلى يسار رأس العمود المطابق لها، متسلسلة إلى نهاية الصف.

رسم توضيحي بسيط (مفتاح JSON الوارد → حيث يجب أن يذهب مقابل حيث ينتهي به الحال):

header: ... | colN  | colN+1 | colN+2 | colN+3
should:     | (empty)| fieldA | fieldB | fieldC
actual:     | fieldA | fieldB | fieldC | (empty)   ← كل شيء منزاح 1 إلى اليسار من colN

نقطة مهمة: جانب القراءة صحيح — المشكلة في الكتابة التي تضع البيانات في المكان الخاطئ. يظهر JSON الناتج من عقدة Append على سبيل المثال fieldA: "X" ويبلغ عن النجاح، لكن قراءة نفس الصف مرة أخرى من خلال المفتاح ترجع fieldA: "Y" (قيمة العمود المجاور). تمت كتابة القيمة في عمود واحد بعيدًا. لاحقًا، أي أعمدة صيغة داخل الورقة والخطوة التالية في Update ثم يتم حلها مقابل الخلايا الخاطئة وترجع #REF!.

لذا فإن مطابقة Auto-Map للاسم→العمود تفشل جزئيًا: الأعمدة المبكرة تتطابق، كتلة لاحقة متجاورة منزاحة بمقدار واحد.

خصائص الورقة التي يبدو أنها تؤدي إلى ذلك (الورقة البسيطة لا تعيد إنتاجها):

  • ورقة عريضة (حوالي 150 عمود)، يوفر سير العمل فقط حوالي 30 منها؛ الباقي فارغ أو أعمدة صيغة داخل الورقة.

  • اسم رأس العمود المكرر (نص رأس عمود متطابق في عمودين مختلفين).

  • عمود قيمته كائن متداخل / بلوب JSON وليس قيمة عددية.

يتم استخدام هذا النمط (Append → قراءة مرة أخرى → Update مع سياق صف/صيغة) عبر عدد من سير العمل، لذا فهو يؤثر على جميعها.

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

لا خطأ في العقدة — Append/Update تبلغ عن النجاح. الفشل الوحيد المرئي هو #REF! في صيغ الورقة التابعة، الناجمة عن انزياح الأعمدة العكسي.

أسئلة للفريق:

  1. هل تغيرت منطق دقة أعمدة Auto-Map لـ Google Sheets typeVersion 3 بين الإصدارات الأخيرة و 2.22.5؟ (هل يتم الآن توجيه v3 من خلال كود مختلف؟)

  2. هل رؤوس الأعمدة المكررة و/أو قيم الخلايا من النوع الكائن المتداخل معروفة بأنها تكسر محاذاة أعمدة Auto-Map في الإصدارات الحالية؟

  3. المسار الموصى به — نقل هذه العقد إلى “Map Each Column” صريح، الترقية إلى عقدة 4.x، أم هذا انحدار v3 يستحق الترقيع؟

سير العمل / الناتج: يسعدني أن أشارك سير عمل الحد الأدنى من النسخ المحاكاة المعقم وصف الصف قبل/بعد عند الطلب.

إعداد n8n

  • إصدار n8n: 2.22.5 (تم الترقية من حوالي 10 إصدارات سابقة، الوسم السابق الدقيق غير معروف)

  • قاعدة البيانات: PostgreSQL

  • EXECUTIONS_PROCESS: main

  • التشغيل عبر: Docker، مع العمال

  • نظام التشغيل: Ubuntu

  • عقدة Google Sheets: typeVersion 3 (لم تتغير عبر الترقية)

2

مرحبا @Dwayne_Taylor

بياناتك تتحول لأن ميزة “التعيين التلقائي” في n8n تشعر بالارتباك حول أي جزء من المعلومات ينتمي إلى أي عمود. فكر فيها مثل حزام ناقل: بمجرد أن يصطدم النظام برطم—مثل اسم عمود يظهر مرتين أو جزء بيانات معقد—يفقد مكانه. لأنه لا يعرف أين يضع هذا العنصر المحدد، فإنه يدفع دون قصد كل شيء يليه مكانا واحدا إلى اليسار، مما يسبب تأثير الدومينو لبيانات غير صحيحة لبقية الصف.

من المرجح أن يحدث هذا الآن لأن التحديث الأخير لـ n8n غيّر الطريقة التي يحسب بها البرنامج هذه المواضع خلف الكواليس. على الرغم من أنك لم تغيّر عقدك، فقد تم تحديث “المحرك” الذي يشغلها. في ورقة عريضة بها رؤوس مكررة، يكافح النظام لتمييز الأعمدة التي تحمل نفس الاسم، مما يؤدي إلى عدم المحاذاة ويؤدي إلى الصيغ المكسورة التي تراها في جدول البيانات الخاص بك.

لإصلاح هذا، الخطوة الأكثر أمانا هي التوقف عن الاعتماد على “التعيين التلقائي” والتبديل إلى “تعيين كل عمود” لسير العمل الحرج لديك. من خلال إخبار n8n يدويا بالضبط أي حقل يدخل في أي عمود، فإنك تزيل التخمين وتمنع النظام من تحريك بياناتك. إذا كان بإمكانك، فإن إعادة تسمية رؤوسك المكررة لتكون فريدة ستحل أيضا السبب الجذري للارتباك.

هل ساعد هذا؟

3

بالإضافة إلى التحويل إلى «Map Each Column»، هناك خيار آخر يستحق المحاولة: ترقية عقدة Google Sheets إلى أحدث typeVersion (4.7) (عن طريق تحرير JSON لهذه العقدة). أعادت TypeVersion 4 كتابة طريقة عمل مطابقة الأعمدة داخليًا، لذلك من المحتمل ألا تتأثر مشكلة Auto-Map shift المرتبطة بسلوك typeVersion 3 في إصدارات n8n الأحدث. يستحق المحاولة قبل إعادة تعيين جميع الأعمدة الـ 150 يدويًا.

4

مرحبا بالفريق - شكرا على المتابعة السريعة

هل هذا يفترض أن أسماء الأعمدة بها تكرار؟
بعض أوراق العمل الخاصة بي كان بها تكرارات والبعض الآخر لم يكن بها ولكنها كانت تظهر أخطاء على أي حال

أيضا @nguyenthieutoan هل لديك توثيق حول ترقية العقدة - أنا لا أرى الوظيفة التي تشير إليها

5

مرحبا @Dwayne_Taylor

أعتذر، يجب عليك تعديل إصدار العقدة يدويًا عن طريق تعديل JSON لهذه العقدة.

بناءً على ما تم مشاركته أعلاه، هناك عدة أنماط جداول تبدو أنها تجعل Auto-Map في typeVersion 3 أسهل كثيرًا في الانقطاع بعد ترقية n8n:

  • جداول عريضة جدًا (~150+ عمود) حيث تكتب سير العمل فقط إلى مجموعة صغيرة من الأعمدة والباقي فارغ أو أعمدة الصيغ.
  • أسماء رؤوس مكررة – يعتمد Auto-Map على نص الرأس، لذلك قد تربك الأسماء المتطابقة منطق المطابقة.
  • أسماء الرؤوس ذات الأحرف الخاصة (على سبيل المثال، فواصل الأسطر)، والتي تقبلها جداول Google ولكن n8n لا يتعرف عليها دائمًا باعتبارها نفس الاسم.
  • الأعمدة التي تخزن الكائنات المتداخلة / كتل JSON بدلاً من القيم العددية البسيطة.

عند دمج عدد قليل من هذه معًا، هذا بالضبط حيث نبدأ في رؤية تحول "عمود واحد إلى اليسار" الذي وصفته، على الرغم من أن العقدة نفسها لم تتغير. في تلك الحالات، يعتبر نقل التدفقات الحرجة إلى "Map Each Column" الصريح على إصدار Sheets الأحدث عادةً هو الإصلاح الأكثر موثوقية على المدى الطويل.

6

@Dwayne_Taylor بخصوص تحديث typeVersion — افتح سير العمل المتأثر، انقر على قائمة ... (أعلى يمين الكانفاس) → Download. افتح ملف JSON المُنزّل في محرر نصوص وابحث عن عقدة Google Sheets الخاصة بك، ثم غيّر typeVersion من 3 إلى 4.7 وأضف حقل الوضع المطابق. يبدو قبل/بعد كالتالي:

{
  "before": {
    "parameters": {
      "operation": "append",
      "documentId": "...",
      "sheetName": "...",
      "dataMode": "autoMapInputData"
    },
    "type": "n8n-nodes-base.googleSheets",
    "typeVersion": 3
  },
  "after": {
    "parameters": {
      "operation": "append",
      "documentId": "...",
      "sheetName": "...",
      "columns": {
        "mappingMode": "defineBelow",
        "matchingColumns": ["row_id"],
        "value": {}
      }
    },
    "type": "n8n-nodes-base.googleSheets",
    "typeVersion": 4.7
  }
}

ثم استورد JSON المعدّل مرة أخرى (أعلى اليمين ... → Import). تستخدم عقدة v4 ربط defineBelow حيث تربط كل حقل إدخال بشكل صريح بعمود الورقة، لذا فإن رؤوس العناوين المكررة + الأوراق الواسعة بـ 150 عمود تتوقف عن كونها مشكلة.

فيما يتعلق بسؤالك الأول (هل ينطبق بدون عناوين مكررة) — نعم، تكمن نفس منطق المطابقة تحت جميع الأنماط الـ 4 التي أدرجها @nguyenthieutoan (الأوراق الواسعة المتفرقة، الأحرف الخاصة في العناوين، الكائنات المتداخلة). العناوين المكررة هي ببساطة الأكثر وضوحاً. إذا كانت بعض الأوراق المتأثرة لديك لا تحتوي على عناوين مكررة، فأنت على الأرجح تواجه واحدة من الحالات الأخرى — الحالة الأكثر احتمالاً هي حالة الكائن المتداخل لأنك قلت أن v3 كان يقرأ بشكل صحيح لكنه يكتب بشكل خاطئ (مسلسل JSON blob في v3 يتسرب إلى الأعمدة المجاورة عندما تكون الحقول متفرقة).