خطأ DOMMatrix غير معرّف عند استخدام مُحمّل البيانات الافتراضي مع PDF

أسئلة
1

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

عند استخدام عقدة Default Data Loader لتحميل ملف PDF ثنائي، يفشل التنفيذ مع الخطأ التالي:

"errorMessage": "DOMMatrix is not defined",
"errorDescription": "DOMMatrix is not defined"

تُسجل أيضًا التحذيرات التالية في الحاوية:

Warning: Cannot load "@napi-rs/canvas" package: "Error: Failed to load native binding".
Warning: Cannot polyfill `DOMMatrix`, rendering may be broken.
Warning: Cannot polyfill `ImageData`, rendering may be broken.
Warning: Cannot polyfill `Path2D`, rendering may be broken.

خطوات إعادة الإنتاج

  1. قم بإعداد سير عمل باستخدام مصدر PDF ثنائي (مثل Google Drive أو Webhook أو عقدة النموذج).
  2. قم بتوصيل المخرج الثنائي بعقدة Default Data Loader مع تعيين نوع البيانات إلى Binary.
  3. نفّذ سير العمل.

السلوك المتوقع

يجب أن تقوم عقدة Default Data Loader بتحليل ملف PDF بنجاح وتمرير المحتوى إلى المرحلة التالية.

السلوك الفعلي

تفشل العقدة مع DOMMatrix is not defined. لا يمكن تحميل حزمة @napi-rs/canvas، مما يمنع pdfjs-dist من إضافة بدائل واجهات برمجية أصلية مطلوبة للمتصفح.

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

  • إصدار n8n: 2.25.7 (موزع ذاتيًا)
  • تشغيل n8n عبر: Docker
  • وضع البيانات الثنائية: نظام الملفات

سياق إضافي

يبدو أن هذه المشكلة تم إدخالها في الإصدار v1.98.0 عند ترقية pdfjs-dist إلى إصدار يعتمد على واجهات برمجية أصلية للمتصفح غير متاحة في بيئات خادم Node.js. تم الإبلاغ عنها من قبل عدة مستخدمين في الإصدارات السابقة وتبدو مستمرة في الإصدار v2.25.7.

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

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

شارك المخرجات التي أرجعتها العقدة الأخيرة

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

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

أعتقد أننا نظرنا إلى هذا الشيء بالضبط اليوم.

جرّب أحدث إصدار تجريبي؛ فقد حل المشكلة بالنسبة لنا.

4

أثناء انتظار اختبار بيتا @menouaw، هناك حل بديل موثوق تم تأكيده عبر مواضيع “DOMMatrix is not defined” ذات الصلة: تحويل ملف PDF إلى نص قبل استخدام Default Data Loader باستخدام عقدة Extract from File (العملية: “PDF”) في وقت سابق من السلسلة ليس كافياً بذاته لأنه يواجه نفس مسار pdfjs-dist/@napi-rs/canvas.

5

مرحباً @menouaw!

الإصلاح في أحدث إصدار تجريبي هو المسار الصحيح على المدى الطويل (اقتراح BramKn). كحل مؤقت بينما أنت على الإصدار المستقر: استخدم عقدة HTTP Request لاستدعاء API خارجية لتحويل PDF إلى نص (مثل Docparser أو Reducto أو أي نقطة نهاية Tika/Unstructured مستضافة ذاتياً) بدلاً من Default Data Loader. بهذه الطريقة يصل نص PDF الخاص بك كـ JSON عادي دون المرور عبر مسار pdfjs + @napi-rs/canvas الذي يسبب الانهيار. أو بدلاً من ذلك، إذا كانت صورة Docker الخاصة بك مبنية على Alpine، فإن الربطات الأصلية المفقودة عادة ما تُصحح بالتبديل إلى n8nio/n8n:latest (المستندة إلى Debian) بدلاً من متغير Alpine.