عقدة Google Sheets Trigger الخاصة بي (الاستقصاء كل دقيقة، حدث rowAdded) تفشل بشكل متقطع مع خطأ 503 عبر سير عملين منفصلين يراقبان جدولي Google Sheets مختلفين بموجب بيانات اعتماد OAuth2 مختلفة. حدث هذا بشكل متكرر من يوليو 12 06:56 حتى يوليو 13 23:03.
لقد تحققت بالفعل من الأسباب القياسية قبل النشر:
بيانات اعتماد Google Sheets OAuth2 الخاصة بي تظهر “الحساب متصل” ولا تحتاج إلى إعادة تفويض.
صفحة حالة n8n الخاصة بـ n8n تظهر حادثة واحدة (20 دقيقة في يوليو 13، من 10:58 إلى 11:18 بالتوقيت المحلي)، لكنها لا تتداخل مع أي من طوابع أوقات الأخطاء الخاصة بي.
لوحة معلومات حالة Google Workspace تظهر Sheets كصحي طوال الفترة.
كان Retry On Fail مفعلاً بالفعل على أحد سير العمل المتأثرين قبل بدء هذه الأخطاء، واستمرت الأخطاء على أي حال، لذا لا يبدو أن هذا خلل مؤقت عادي يمكن للإعادة امتصاصه.
وجدت خيطين سابقين متشابهين (مرتبطين أدناه) حيث كان الإصلاح المقترح هو تفعيل Retry On Fail، لكن بما أن هذا كان مفعلاً بالفعل على أحد سير العمل الخاصة بي ولم يساعد، أردت الإشارة إلى هذا كمشكلة ممكن أن تكون مختلفة أو أكثر استمراراً.
الخيوط ذات الصلة التي وجدتها:
ما هي رسالة الخطأ (إن وجدت)؟
{
“errorMessage”: “Service unavailable - try again later or consider setting this node to retry automatically (in the node settings)”,
“errorDescription”: “The service is currently unavailable.”,
“errorDetails”: {},
“n8nDetails”: {
“n8nVersion”: “2.29.8 (Cloud)”,
“binaryDataMode”: “filesystem”
}
}
يرجى مشاركة سير العمل الخاص بك
(حدد العقد على لوحتك واستخدم اختصارات لوحة المفاتيح CMD+C/CTRL+C و
الاستقصاء كل دقيقة يستهلك موارد كثيرة وعرضة لهذه الأخطاء. الطريقة الأكثر قوة للتعامل مع أحداث “إضافة صف” هي جعل جداول بيانات Google تدفع البيانات إلى n8n فوراً باستخدام برنامج Google Apps Script بسيط.
استبدل محفز جداول بيانات Google بـ عقدة Webhook في n8n.
انسخ عنوان URL لـ Webhook الإنتاج.
في جدول البيانات الخاص بك، انتقل إلى الإضافات →→ Apps Script والصق برنامجاً نصياً مشابهاً لهذا:
function onFormSubmit(e) {
var url = "YOUR_N8N_WEBHOOK_URL";
var options = {
"method": "post",
"contentType": "application/json",
"payload": JSON.stringify(e.values)
};
UrlFetchApp.fetch(url, options);
}
قم بإعداد محفز قابل للتثبيت في لوحة معلومات Apps Script (رمز الساعة) لتشغيل دالة onFormSubmit عند “إرسال النموذج” أو “عند التغيير”.
رمز الخطأ 503 هنا يأتي من واجهة برمجة تطبيقات Google، وليس من n8n - يستدعي محفز استقصاء Sheets واجهة برمجة تطبيقات Sheets في كل فترة زمنية، وأحياناً تسقط Google الطلبات على حافة الخدمة حتى عندما تبدو صفحة الحالة العامة خضراء. هناك شيئان يجب التحقق منهما: أولاً، انظر إلى نص الخطأ الأولي في سجل التنفيذ - إذا كان يتضمن backendError أو serviceUnavailable في JSON، فهذا يؤكد أن الواجهة الخلفية لـ Google هي المسؤولة. ثانياً، حاول تبديل فترة الاستقصاء إلى كل 5 دقائق بدلاً من كل دقيقة واحدة - الاستقصاء المكثف مع بيانات اعتماد متعددة تضرب نفس حصة واجهة برمجة تطبيقات Sheets يمكن أن يفاقم هذا. إذا كنت بحاجة إلى كشف قريب من الوقت الفعلي، فإن التبديل إلى نهج قائم على webhook عبر Google Apps Script (ينشئ webhook n8n الخاص بك عند تغيير الورقة) أكثر موثوقية من الاستقصاء ويتجنب هذا النوع من الأخطاء بالكامل.
مرحبا @Kalon
إذا كانت كلا بيانات الاعتماد من نوع “Sign in with Google” المدار OAuth2، فإنها تمر عبر عميل Google المشترك في n8n على Cloud، وهذا هو السبب في فشل حسابين مختلفين في نفس النوافذ وسبب عدم وجود لوحة تحكم API للبحث فيها. أعد إنشاء بيانات الاعتماد كـ Custom OAuth2 باستخدام عميل من مشروع Google Cloud الخاص بك وأشر كلا سير العمل إليه. ثم افتح APIs and Services > Google Sheets API > Metrics في هذا المشروع: يوضح توزيع رمز الاستجابة السبب الذي تعلقه Google بكل 503، وتعمل استطلاعاتك مقابل عميلك الخاص بدلاً من العميل المشترك.
الخطأ 503 يأتي من جانب Google، وليس من جانب n8n — وعلى n8n Cloud، يستخدم Sheets Trigger عميل Google OAuth المشترك من n8n، لذا أنت تشارك حصة API لعميل هذا مع كل مستخدم Cloud آخر. عندما تقيد Google المشروع المشترك هذا، تحصل على أخطاء 503 متقطعة حتى لو كانت بيانات اعتمادك الخاصة والحجم على ما يرام. هذا هو السبب في أنه يؤثر على سير العمل كليهما تحت بيانات اعتماد مختلفة في نفس الوقت، ولماذا لا يمحو Retry On Fail المشكلة — محفز الاستطلاع لا يعيد مسح الصفوف التي تخطاها أثناء الدورات الفاشلة، لذا الخطر الحقيقي هنا هو الصفوف المفقودة بصمت، وليس سطر الخطأ نفسه.
إصلاحان، بترتيب التأثير:
الانتقال إلى Custom OAuth2 — أنشئ مشروع Google Cloud الخاص بك + عميل OAuth واستخدمه كبيانات الاعتماد. هذا ينقلك من الحصة المشتركة إلى حصتك الخاصة، مما يقضي عادةً على أخطاء 503 المتقطعة تماماً.
استبدال الاستطلاع بالدفع — محفز onChange لـ Google Apps Script يرسل صفوفاً جديدة عبر POST إلى Webhook من n8n. لا يوجد استطلاع يعني عدم وجود نافذة صفوف مفقودة (لف جانب Apps Script في try/catch، لأنه له حصصه الخاصة).
على أي حال، أضف شبكة أمان صغيرة: سير عمل مجدول كل 15-30 دقيقة يعيد قراءة آخر ساعة من الصفوف ويزيل التكرار بناءً على معرّف الصف أو عمود الطابع الزمني — حتى يتم التقاط أي شيء تم حذفه أثناء نافذة 503.
شرح العميل المشترك في OAuth أعلاه صحيح جداً على الأرجح، والانتقال إلى عميل مخصص هو الخطوة الصحيحة التالية. لكن الجميع هنا (أنا أيضاً، حتى أعدت قراءة منشورك) يجادلون حول أي استطلاع يجب إصلاحه، وأعتقد أن السؤال الأكثر فائدة هو لماذا تقوم بالاستطلاع على الإطلاق.
rowAdded بفاصل زمني مدته 60 ثانية يعني أن n8n يسأل Google “هل حدث أي تغيير؟” 1,440 مرة يومياً، لكل سير عمل، للأبد — والأغلبية الساحقة من تلك الاستدعاءات لا ترجع شيئاً. كل واحدة منها فرصة للحصول على 503، والانتقال إلى عميل OAuth الخاص بك يقلل من هذا التعرض دون إزالته، لأن 503 هو ما يرجعه الخادم الخلفي لـ Google تحت الحمل بغض النظر عن عميل من تكون.
ادفع بدلاً من الاستطلاع. في الجدول: Extensions → Apps Script، ثم شيء مثل:
function onRowAdded(e) {
UrlFetchApp.fetch('https://<your-n8n>/webhook/<path>', {
method: 'post',
contentType: 'application/json',
payload: JSON.stringify({ range: e.range.getA1Notation(), values: e.range.getValues() })
});
}
```
...مرتبط كمشغل قابل للتثبيت (Triggers → Add Trigger → On change، أو On form submit إذا وصلت الصفوف من نموذج). في n8n، استبدل Sheets Trigger بعقدة Webhook.
ما الذي يحصل عليه: **صفر استدعاءات Sheets API**، لذا فإن فئة الأعطال الكاملة التي تتابعها تختفي بدلاً من أن تصبح أقل تكراراً. يعمل Apps Script *داخل* Sheets ولا يلمس Sheets REST API أو حصته، لذا لا يمكن لـ Google API 503 أن يسقط حدثك. إنه أيضاً فوري بدلاً من التأخر لمدة تصل إلى 60 ثانية، وهو مجاني.
تحفظان صادقان، لأن هذا ليس مجاناً:
- `onChange` لا يتم تشغيله للتعديلات التي أجرتها *كتابات* API أو برامج نصية أخرى. إذا وصلت بعض الصفوف عبر Sheets API بدلاً من البشر أو نموذج، فلن تؤدي إلى تشغيله — تحقق من كيفية وصول الصفوف بالفعل قبل الالتزام.
- أنت الآن تعتمد على وصول webhook الخاص بك. لن يعيد محاولة Apps Script بشكل ذي معنى، لذا سيؤدي إعادة تشغيل n8n أثناء POST إلى فقدان هذا الحدث.
وهذا هو السبب في أن مسح الشبكة الأمنية المقترح أعلاه يبقى بغض النظر عن المشغل الذي تستخدمه: سير عمل مجدول يعيد قراءة آخر N من الصفوف والتفريغ على معرف صف. ادفع بحثاً عن الكمون، امسح بحثاً عن الصحة. هذا الجمع هو ما سأشغله في الإنتاج، وهو ما يجعل "هل فاتني صف بصمت أثناء نافذة 503؟" سؤال يمكنك فعلاً الإجابة عليه بدلاً من افتراضه.
شيء واحد أخير يستحق التحقق قبل أن تمضي قدماً: هل فُقدت أي صفوف بالفعل *أثناء* نوافذ الفشل تلك، أم أن الاستطلاع الناجح التالي التقطها؟ 503s مزعجة ومحبطة، لكن فقدان البيانات الصامت هو الشيء الذي قد يؤذيك بالفعل، ويستحق التأكد من أيهما كان لديك.
@Kalon
خطأ 503 Service Unavailable في n8n (Google Sheets Trigger) يشير إلى مشكلة مؤقتة على جانب خادم الوجهة—في هذه الحالة، Google Sheets API غير قادر مؤقتاً على معالجة الطلب.
يمكن تقسيم الأسباب والحلول على النحو التالي:
ما الذي يسبب ذلك؟
حمل زائد على خوادم Google أو توقف مؤقت (Transient Error): هذا هو السبب الأكثر شيوعاً. قد تكون خوادم Google قيد إعادة التشغيل أو الصيانة أو معالجة حجم حركة مرور غير عادي في تلك اللحظة المحددة.
الاستقصاء بتكرار كبير جداً: سير العمل يتحقق من التحديثات كل دقيقة واحدة. تشغيل مشغل الاستقصاء بهذا التكرار العالي يمكن أن يتسبب في رؤية Google API للطلبات على أنها عدوانية جداً، مما يؤدي إلى قطع الاتصال مؤقتاً لمنع الحمل الزائد (حتى لو لم تعيد صراحةً خطأ 429 Too Many Requests).
مشاكل شبكية متقطعة: قد يكون هناك انقطاع اتصال قصير أو انتظار انقطاع المصافحة بين مثيل n8n الخاص بك وخوادم Google.
كيفية إصلاحه؟
1. تفعيل “Retry On Fail” (كما هو موصى به من قبل النظام) هذه هي الطريقة الأكثر فعالية للتعامل مع هذه الأنواع من الأخطاء العابرة.
انتقل إلى Node Settings (أيقونة الترس) لمشغل Google Sheets.
قم بتشغيل Retry On Fail.
قم بتكوين عدد محاولات إعادة المحاولة (على سبيل المثال، 3 مرات) ووقت الانتظار بين المحاولات. وهذا يمنع سير العمل من التعطل فوراً عند مصادفة خطأ 503 مؤقت.
2. زيادة فترة الاستقصاء إذا كان مشغلك يتحقق من البيانات بتكرار كبير جداً (مثل كل دقيقة)، فيمكنك النظر في تمديد الفترة لتقليل إجمالي حمل API.
غيّر الفترة للتحقق كل 5 دقائق أو 15 دقيقة إذا لم تكن التحديثات في الوقت الفعلي ضرورية بشكل صارم لحالتك.
3. تحقق من حصص Google Cloud Console إذا كنت تستخدم بيانات اعتماد OAuth2 مخصصة خاصة بك (بدلاً من بيانات اعتماد السحابة الافتراضية لـ n8n):
قم بتسجيل الدخول إلى Google Cloud Console وتحقق من قسم الحصص (Quotas) لـ Google Sheets API للتأكد من أنك لا تضرب قيود الحد الأقصى في الدقيقة أو في اليوم.
4. تحقق من حالة خدمة Google أحياناً تواجه Google Workspace نفسها انقطاعات. يمكنك مراقبة صحة خدماتهم في الوقت الفعلي على لوحة معلومات حالة Google Workspace. إذا كانت Google تواجه انقطاعاً واسع النطاق، فستحتاج فقط إلى الانتظار حتى يحل فريقهم المشكلة.
عادةً ما يكون 503 فشلاً مؤقتاً من جانب Google، لكنني لن أجمعه تلقائياً مع مشاكل الحصص أو الاستطلاع العدواني. إذا اعتقدت Google أنك تتجاوز الحصص، فعادةً ما ترى 429 أو استجابات 403 المتعلقة بالحصص، وليس 503.
أيضاً، لست مقتنعاً بأن تفعيل إعادة المحاولة عند الفشل هو بالضرورة الإجابة هنا إذا كان الفشل يحدث على مستوى استطلاع الزناد نفسه. تتصرف عقد الزناد بشكل مختلف عن عقد سير العمل العادية، لذا سيكون من المفيد تأكيد ما إذا كانت إعادة المحاولات تنطبق فعلاً على فشل استطلاع Google Sheets Trigger أم فقط على تنفيذ العقد اللاحقة.
شرح OAuth المشترك يبدو أكثر إقناعاً بكثير، خاصة وأن عدة مستخدمين يبدو أنهم يرون هذا في نفس الوقت تقريباً. الانتقال إلى عميل OAuth مخصص يعزلك عن السلوك العميل المشترك وهو على الأرجح أول شيء سأختبره.
ومع ذلك، أعتقد أن السؤال الأكثر أهمية هو السؤال الذي طرحه Adam في وقت سابق:
هل فُقد فعلاً أي شيء؟
هل تم تفويت الصفوف بشكل دائم، أم أن الاستطلاع الناجح التالي ببساطة اقترب ومعالجتها بشكل طبيعي؟
لأن هناك فرقاً كبيراً بين:
أخطاء 503 المؤقتة الصاخبة في السجلات، و
فقدان البيانات الصامت.
الأول مزعج.
الثاني مشكلة إنتاج.
فيما يتعلق باقتراح Apps Script، هناك تفصيل واحد مهم يستحق الذكر:
e.range وe.values تعمل لأنواع معينة من الزناد مثل عند تقديم النموذج، لكن لا يُضمن وجودهما في زناد عند التغيير القابل للتثبيت العام. لذا قد يعمل تطبيق المثال بشكل مثالي لبعض سير العمل ويفشل فوراً للآخرين اعتماداً على كيفية دخول الصفوف إلى الورقة.
نهج webhook لا يزال جذاباً لأن إزالة الاستطلاع تزيل فئة كاملة من فشل الاستطلاع، لكنها تقدم وضعاً مختلفاً للفشل بدلاً من ذلك:
إذا كان endpoint webhook غير متاح أثناء التسليم، لن تعطيك Apps Script إعادة محاولات دائمة أو قائمة انتظار.
شخصياً سأقوم بتشغيل:
تسليم push/webhook لزمن انتقال منخفض،
معالجة idempotent باستخدام معرف الصف،
وسير عمل مصالحة مجدول يعيد فحص الصفوف الحديثة بشكل دوري.
Push للسرعة.
المسح للصحة.
هذا المزيج يتحمل الأعطال في واجهة برمجة التطبيقات، وتوقف webhook، وإعادة تشغيل سير العمل وتقريباً كل حالة حدية قبيحة تظهر في النهاية في الإنتاج.
في هذه المرحلة سأكون مهتماً بثلاثة أشياء قبل استخلاص الاستنتاجات:
OAuth مشترك على n8n أم OAuth مخصص؟
هل تم فعلاً تفويت أي صفوف؟
هل جميع المستخدمين المتأثرين يعملون في نفس منطقة n8n Cloud أم البنية الأساسية؟
على الأرجح أن تلك الإجابات تخبرنا ما إذا كنا ننظر إلى فشل Google المؤقت المتوقع أم حادثة فعلية من جانب n8n تستحق مزيداً من التحقيق.
عادةً ما يشير خطأ 503 Service Unavailable إلى أن خادم Google Sheets API مثقل مؤقتاً أو يفرض حدود معدل صارمة بسبب التزامن العالي.
نظراً لأنك تقوم باستطلاع كل دقيقة واحدة عبر عدة سير عمل منفصلة وبيانات اعتماد OAuth، فمن المحتمل جداً أنك تؤدي إلى تجاوز حصص الطلبات المتزامنة من Google، مما يسبب رفض الطلبات بشكل متقطع. نظراً لأن “إعادة المحاولة عند الفشل” مع التأخيرات القصيرة الافتراضية لا تلتقطه، فإن مدة الحجب تتجاوز محاولات إعادة المحاولة.
إليك طريقتان لحل هذه المشكلة بشكل دائم:
الاستطلاع الديناميكي والتراجع الأسي (الإصلاح السريع):
• انتقل إلى إعدادات عقدة Google Sheets → تحت “إعادة المحاولة عند الفشل”، قم بزيادة الحد الأقصى للمحاولات إلى 5.
• قم بزيادة تأخير إعادة المحاولة (وقت الانتظار) إلى 5000ms على الأقل أو 10000ms. هذا يعطي Google API وقتاً كافياً للهدوء بين إعادة المحاولات لامتصاص كتلة 503 العابرة.
الانتقال من الاستطلاع إلى بنية الدفع عبر Webhooks (موصى به ):
بدلاً من أن يقوم n8n باستطلاع Google Sheets كل دقيقة، يمكنك عكس البنية.
• استبدل محفز Google Sheets بعقدة n8n Webhook.
• أضف برنامج Google Apps Script بسيط بـ 5 أسطر (محفز onEdit) إلى جداول Google التي ترسل تلقائياً طلب POST إلى n8n Webhook الخاص بك كلما تمت إضافة صف جديد.
هذا يتجاوز تماماً حدود معدل الاستطلاع، ويلغي أخطاء 503 بالكامل، ويوفر قدراً ضخماً من النفقات العامة لتنفيذ n8n.
أخبرني إذا كنت تحتاج إلى مساعدة في هيكلة إعداد Google Apps Script، يمكنني مشاركة كتلة البرنامج النصي معك!
):