Sentry-javascript: استرجع الوعد من طرق الالتقاط * الرئيسية لواجهة برمجة التطبيقات

شكرًا لإبراز هذا ، لتوضيح أنه ليس متزامنًا بشكل كامل ، فإن "النقل" يعمل في الخلفية. لذا ، بالمعنى الدقيق للكلمة ، ليس مضمونًا أن يصل الحدث إلى Sentry.

يتم إنشاء eventId في SDK محليًا وسيتم استخدامه لاستيعاب الحدث على الخادم.

سنقوم بتحديث مستنداتنا لتوضيح ذلك.

حسنًا ، للتوضيح فقط ، من الضروري بالفعل تنفيذ ما هو موضح هنا: https://docs.sentry.io/error-reporting/configuration/draining/؟

هل هذا صحيح ،HazAT؟

rhyek Corrent ، إذا كنت تريد التأكد من إرسال كل شيء ، فيمكنك انتظار التدفق للتأكد من إرسال كل شيء.

ألن يكون من الأفضل مجرد فضح الوعد من طرق capture* ؟ ستكون واجهة برمجة التطبيقات أكثر وضوحًا منذ إعادة الوعد لإعلام المستخدمين بأنه يتعين عليهم await للتأكد من إرسال الحدث أو مجرد إطلاق النار والنسيان على أمل إرساله. كل من close و flush هما طريقتان للأداة المساعدة الغامضة التي تحاول إنشاء شيء متزامن يعتقد أنه غير متزامن. بالإضافة إلى ذلك ، كلتا الطريقتين معطلتان تمامًا: في الواقع ، هناك عدد غير قليل من المراوغات (أود أن أقول إنها خطأ ولكن ربما يعتمد هذا على POV للشخص الذي ينظر إليها):

• غرض timeout تم تمريره إلى flush فارغ لأنه لا يتم احترامه بواسطة النقل بمقاطعة إرسال الطلبات. إنه يحل الوعد المرتجع إلى false عند انتهاء صلاحية المؤقت. ما زلت أسأل نفسي عن فائدة هذا الرمز والسلوك ...
• ترجع الطريقة flush وعدًا جديدًا في كل مرة يتم استدعاؤه ، ويتم حله بمجرد الوصول إلى timeout . هناك مشكلتان: الكود الكامل الذي تم تنفيذه بواسطة setInterval بطيء للغاية ، على الأقل في الاختبارات التي أجريتها في وحدة التحكم بالمتصفح ، وتم حل الوعد بعد عدة ثوانٍ من انتهاء المهلة. المشكلة الثانية والأكثر أهمية هي أن رمز الوظيفة _isClientProcessing يمسح المهلة في كل مرة يتم استدعاؤها ، لذلك إذا كان شخص ما يفعل شيئًا مثل Promise.all([fush(), flush()]) (لا أعرف لماذا يجب أن يفعل ولكن بما أن API تقدم وعدًا جديدًا في كل مرة قد يميل إلى القيام بذلك) ، فلن يتم الوفاء بهذا الوعد أبدًا.

كورنت ، إذا كنت تريد التأكد من إرسال كل شيء ، يمكنك انتظار التدفق للتأكد من إرسال كل شيء.

غير صحيح ، راجع نقاطي أعلاه لتفهم لماذا لا يمكنك التأكد من إرسال كل شيء حتى في انتظار التدفق. أود أن أقول إن تصميم واجهة برمجة التطبيقات هذا معطل تمامًا ولا يمكنني حقًا أن أفهم لماذا لا نترك للمستخدم خيار انتظار الوعود التي تمثل إرسال حدث بدلاً من محاولة إنشاء واجهة برمجة تطبيقات لإيقاف التشغيل لا يمكنها حتى أن تعمل للجميع اللغات التي يجب أن تعمل فيها واجهة برمجة التطبيقات الموحدة

أعتقد أن الوصول إلى وعد يقرر عندما ينتهي الحدث أخيرًا
ترسل بالإضافة إلى الطرق الأخرى الموضحة في هذا الموضوع يجعل ملف
الكثير من المعنى.

يوم السبت 11 مايو 2019 الساعة 12:29 مساءً Stefano Arlandini [email protected]
كتب:

ألن يكون من الأفضل مجرد فضح الوعد من الأسطوانة *
طرق؟ ستكون واجهة برمجة التطبيقات أكثر وضوحًا منذ تقديم الوعد لإعلام المستخدمين بذلك
عليهم انتظار ذلك للتأكد من إرسال الحدث أو مجرد إرساله
أطلق النار وانسى على أمل أن يتم إرسالها. كل من الإغلاق والتدفق هما من طرق
فائدة غامضة تحاول أن تجعل شيئًا متزامنًا كان
فكر في أن تكون غير متزامن. بالإضافة إلى ذلك ، كلتا الطريقتين معطلتان تمامًا: في
في الحقيقة ، هناك عدد غير قليل من المراوغات (أود أن أقول إنها خطأ ولكن
ربما هذا يعتمد على وجهة نظر الشخص الذي ينظر إليهم):

• الغرض من المهلة المنقضية للتدفق فارغ لأنه ليس كذلك
  احترامها بالنقل بمقاطعة إرسال الطلبات. هو - هي
  فقط يحل الوعد المرتجع إلى خطأ عند انتهاء صلاحية المؤقت.
  ما زلت أسأل نفسي عن فائدة هذا الرمز والسلوك ...
• تُعيد طريقة التدفق وعدًا جديدًا في كل مرة تُسمى ذلك
  بمجرد الوصول إلى المهلة. هناك مشكلتان:
  الشفرة الكاملة التي تنفذها setInterval بطيئة للغاية ، على الأقل في
  اختباراتي في وحدة التحكم بالمتصفح ، وحلت الوعد كثيرًا
  ثوان بعد انتهاء المهلة. المشكلة الثانية والأكثر أهمية هي
  أن رمز الدالة _isClientProcessing يمسح المهلة
  في كل مرة يتم الاتصال بها ، لذلك إذا كان هناك شخص ما يفعل شيئًا مثل Promise.all ([fush () ،
  flush ()]) (لا أعرف لماذا يجب أن يفعل ذلك ، ولكن منذ عودة API
  وعد جديد في كل مرة قد يميل إلى القيام به) عندها سيفعل هذا الوعد
  لا تحل ابدا.

كورنت ، إذا كنت تريد التأكد من إرسال كل شيء ، يمكنك انتظار التدفق
للتأكد من إرسال كل شيء.

غير صحيح ، انظر إلى نقاطي أعلاه لفهم سبب انتظارك
لا يمكن التأكد من إرسال كل شيء. أود أن أقول أن تصميم API هذا هو
مكسورة تمامًا ولا أستطيع حقًا أن أفهم لماذا لا تترك للمستخدم ملف
اختيار انتظار الوعود التي تمثل إرسال حدث
بدلاً من محاولة إنشاء واجهة برمجة تطبيقات لإيقاف التشغيل لا يمكنها حتى أن تعمل مع الجميع
اللغات التي يجب أن تعمل فيها واجهة برمجة التطبيقات الموحدة

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/getsentry/sentry-javascript/issues/2049#issuecomment-491533914 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/AAFLTSVSICZ7Y26UHCSMKWLPU4GATANCNFSM4HKUJ5ZQ
.

أود أن أقول أيضًا أنني لا أتوقع أن تقوم طريقة بإرجاع نتيجة لتشغيل شيء ما في الخلفية لأن هذا مصدر ارتباك للمستخدمين (والسؤال الرئيسي لهذه المشكلة بالطبع). بدلاً من ذلك ، إذا تم إرجاع الوعد ، فمن الواضح أنه مجرد عنصر نائب لشيء سيأتي في المستقبل وأنه ليس جاهزًا بعد. من الواضح أن خيار انتظاره أو إطلاقه ونسيانه للمستخدم. أيضًا ، نظرًا لأن معرف الحدث يتم إنشاؤه محليًا (لا أرى أي سبب للقيام بذلك راجع للشغل) ، يمكنك استخدام شيء ما (لأنه يتم إرجاعه بشكل فوري) غير صالح لأنه لسبب ما فشل النقل في إرسال الحدث وأنت لا تفعل ذلك لا أعرف حتى عن ذلك

واجهت مشكلة كبيرة مع Sentry منذ أن قمنا بالترقية إلى @sentry/node ، من المحتمل أن نعود إلى raven-node حتى يكون هناك حل أفضل.

إن الاضطرار إلى استنزاف قوائم الانتظار في المهلات التعسفية في نهاية كل تنفيذ بدون خادم يبدو بالتأكيد أشبه باختراق وليس حلاً. 🤔

بالنسبة لأولئك الذين يبحثون عن مزيد من الأمثلة لما قد ينجح - وجدت بعض الحلول ضمن # 1449 مفيدة حول التنظيف ، ويناقشون الكثير من هذه المشكلة أيضًا.

(إنهم يركزون على Lambdas وبدون خادم ولكن من المحتمل أن تعمل نفس المفاهيم في بيئات أخرى أيضًا لأنها طريقة التنظيف).

بالتأكيد حريصة على أن تكون هناك طريقة أفضل في وقت ما لا تتضمن التنظيف في كل مرة.

أتفق تمامًا مع ما قيل في هذا الموضوع ، IMO من المربك حقًا أن يكون لديك طريقة متزامنة تخفي عدم التزامن في الخلفية.
ربما يكون لدى فريق الحراسة سبب وجيه جدًا للقيام بذلك بهذه الطريقة ، على أي حال ، سيكون من المفيد حقًا تحديث الوثائق.

cibergarri أعتقد أن السبب في ذلك هو أنه يمكن إرجاع معرف الحدث على الفور دون حظر رمز Userland على مكالمة شبكة بطيئة محتملة إلى تطبيق Sentry apis. أوافق على أنه من المربك إرجاع قيمة من واجهة برمجة تطبيقات غير متزامنة ومن المحتمل أن تؤدي إلى فقدان صامت للأخطاء في سياقات تنفيذ بدون خادم والتي لا تبقى لفترة كافية لاستدعاءات طبقة النقل غير المتزامنة. يتمثل أحد الحلول في تقسيم الوظيفة إلى قسمين بحيث يحتاج المستخدم إلى الاشتراك في السلوك غير المتزامن ، على سبيل المثال

Sentry.captureException() // -> returns eventId after successful submission to sentry
Sentry.captureExceptionAsync() // -> returns promise

أو كمعامل ، على سبيل المثال

Sentry.captureException(ex, {async: false}) // ->  default, returns eventId after successful submission to sentry
Sentry.captureException(ex, {async: true}) // -> returns promise

يتم دائمًا إنشاء معرّف الحدث في العميل ، لذلك لا يهم واجهة برمجة التطبيقات (API) المتزامنة أو المتزامنة ، وبالتالي فهي ليست مؤشرًا جيدًا على ما إذا كان الحدث قد تم إرساله أم لا (مشكلة أخرى imo). لقد اقترحت أيضًا منذ فترة طويلة لـ PHP SDK حلاً مشابهًا يتضمن وجود طرق متزامنة وغير متزامنة لكل طريقة capture* ولكن تم رفضها. لم أفهم تمامًا السبب الحقيقي وراء رغبة Unified API في إخفاء عدم التزامن وعدم رغبة المطورين في الكشف عن وعد ، ولكن بدا لي أنهم لم يكونوا منفتحين كثيرًا لتغيير هذا.

للأسف ، جعلتني هذه المشكلة أبتعد عن تطبيق Sentry لأنه جعل أخطاء التتبع في البيئات التي لا تحتوي على خادم معرضة جدًا للخطأ. (يا السخرية.)

طرق capture*Async كانت مفيدة للغاية 👍

هل يمكننا الحصول على تحديث عن هذا؟

marcospgp ماذا تريد أن تعرف بالضبط؟ كل ما كتبه دانيال لا يزال قائما حتى يومنا هذا.

أعتقد أنه بصرف النظر عن التوثيق ، فمن الواضح جدًا من ردود الفعل على التعليقات والتعليقات بأنفسهم أن المستخدمين يرغبون في الوصول إلى الوعود ، وليس هناك سبب وجيه لعدم السماح بهذا imho

لسوء الحظ ، لن يحدث ذلك قبل إصدار v6 ، حيث إنه يكسر التغيير في واجهات برمجة التطبيقات الرئيسية الخاصة بنا وسيتطلب الكثير من التغييرات. سأضيف هذا إلى خارطة الطريق على الرغم من الحفاظ على ذلك ملاحظًا.