Sentry-javascript: @ Sentry / node memory تتسرب على العقدة 10.13.0

abraxxas هل يمكنك مساعدتي في إعادة
لقد جربت وصفك دون حظ ، إنه ينتج إحصائيات أحداث ، ولا يسرب إحداها أبدًا.

kamilogorek شكرا لردكم. ما فعلته كان ما يلي. لقد تحققت من هذا المثال https://github.com/sheerun/next.js/tree/with-sentry-fix/examples/with-sentry وأضفت memwatch إلى server.js

if (!dev) {
  memwatch.on("leak", info => {
    console.log("memwatch::leak");
    console.error(info);
  });

  memwatch.on("stats", stats => {
    console.log("memwatch::stats");
    console.error(Util.inspect(stats, true, null));
  });
}

ثم قمت بتشغيل المثال باستخدام العقدة 10.x (مع ملاحظة 8.xi عدم وجود مشكلات في الذاكرة) وطلبت المصادر التالية باستخدام اختبار جاتلينج الخاص بنا:

    "/",
    "/_next/static/r1zovjaZ1TujaA0hJEp91/pages/_app.js",
    "/_next/static/r1zovjaZ1TujaA0hJEp91/pages/_error.js",
    "/_next/static/r1zovjaZ1TujaA0hJEp91/pages/index.js",
    "/_next/static/runtime/main-1eaa6d1d0c8e7d048efd.js",
    "/_next/static/chunks/commons.b34d260fee0c4a698139.js",
    "/_next/static/runtime/webpack-42652fa8b82c329c0559.js"

(لاحظ أن التجزئة قد تتغير بالنسبة لك)

لكن يجب أن تكون قادرًا على تحقيق نفس النتائج باستخدام هذا النهج البسيط للغاية https://www.simonholywell.com/post/2015/06/parallel-benchmark-many-urls-with-apachebench/

بعد بضعة آلاف من الطلبات ، كان استخدام الذاكرة لدينا عند 1 غيغابايت تقريبًا ولم ينخفض ​​أبدًا حتى عند الخمول. بمجرد إزالة الطلب و errorHandler من server.js ، يتوقف تسرب الذاكرة. لذلك يبدو أنه مرتبط بهذه 2. ربما كان لديك عدد قليل جدًا من الطلبات أو استخدمت العقدة 8.x؟

abraxxas أكد. العقدة 10 + ~ 300req لكل مورد تؤدي المهمة. سوف تحقق أكثر. شكر!

kamilogorek intersting ، ولكن إذا نظرت إلى الحجم الكبير في ملف
الاستنساخ سترى أنه يبقى حوالي 20 ميغا بايت بدون معالجات
بل يزداد بسرعة معهم.

أعتقد أن تحذير تسرب الذاكرة بدون المعالجات يحدث لمجرد
بسبب الطلبات هناك بعض زيادة الذاكرة الثابتة.

لا يزال هناك فرق شاسع في استخدام الذاكرة بين الإصدار ذي
الحارس وبدونه.

في الخميس ، 29 تشرين الثاني (نوفمبر) 2018 ، 12:45 كتب كاميل أوغوريك < [email protected] :

abraxxas https://github.com/abraxxas لقد أعدت إنتاجه بنجاح ،
ومع ذلك ، يبدو أن الخادم لا يزال يتسرب يطلب كائنات من تلقاء نفسه ،
حتى بدون معالجات الحراسة.

https://streamable.com/bad9j

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

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

تجاهل abraxxas تعليقي السابق (الذي أزلته) ، فهو في صالحنا تمامًا :)

يبدو أن المشكلة في جوهر Node نفسه. يرجى الرجوع إلى هذا التعليق https://github.com/getsentry/sentry-javascript/issues/1762#issuecomment -444126990

kamilogorek هل أتيحت لك الفرصة للنظر في هذا حتى الآن؟ إنه يتسبب في تسرب كبير للذاكرة بالنسبة لنا. بعد النظر إلى الكومة ، يبدو أن هذا الخط قد يكون أصل المشكلة:

https://github.com/getsentry/sentry-javascript/blob/c27e1e32d88cc03c8474fcb1e12d5c9a2055a150/packages/node/src/handlers.ts#L233

أظهر المفتش آلاف الإدخالات في قائمة eventProcessors

ليس لدي أي سياق حول كيفية تصميم الأشياء ، لكننا لاحظنا أن الطلبات لا يتم تحديد نطاقها بشكل صحيح وتقدم بيانات وصفية خاطئة (انظر # 1773) لذلك يبدو أن كل شيء تتم إدارته في حالة عالمية ولا يتم تنظيفه عندما ينتهي الطلب

abraxxastpbowden هناك مشكلة مع تسريب وحدة المجال في جوهر عقدة في نفسه. سنستمر في مراقبته ونحاول التوصل إلى حل مؤقت قبل إصلاحه في جوهره. المشكلة ذات الصلة: https://github.com/nodejs/node/issues/23862

kamilogorek هل لديك أي أفكار لحل بديل أو إصلاح مؤقت لهذا؟ يبدو التقدم في مشكلة العقدة بطيئًا جدًا

نحن نستخدم حاليًا PM2 لإعادة تشغيل عمليات Node.js عندما تصل الذاكرة إلى حد معين. https://pm2.io/doc/en/runtime/features/memory-limit/#max -memory-threshold-auto-reload

استخدام المعمل لاختبار الوحدة. التسريبات لا تزال موجودة. أعلم أن التسريبات يمكن أن تكون مؤلمة عند تصحيحها. هل هناك وقت محدد للوصول للإصلاح؟

1 اختبارات كاملة
مدة الاختبار: 1832 مللي ثانية
تم الكشف عن التسريبات التالية: __ extends، __assign، __rest، __decorate، __param، __metadata، __awaiter، __generator، __exportStar، __values، __read، __spread، __await، __asyncGenerator، __StyncDelegator، __importStar

npm خطأ! كود ELIFECYCLE
npm خطأ! يخطئ 1
npm خطأ! [email protected] اختبار: lab build/test
npm خطأ! حالة الخروج 1
npm خطأ!
npm خطأ! فشل في البرنامج النصي [email protected] للاختبار.
npm خطأ! ربما لا تكون هذه مشكلة مع npm. من المحتمل أن يكون هناك مخرجات تسجيل إضافية أعلاه.

npm خطأ! يمكن العثور على سجل كامل لهذا التشغيل في:
npm خطأ! /Users/sunknudsen/.npm/_logs/2019-02-13T14_41_28_595Z-debug.log

sunknudsen تم إصلاح المشكلة بالفعل في NodeJS ، راجع https://github.com/nodejs/node/issues/23862 و https://github.com/nodejs/node/pull/25993. ربما نحتاج إلى انتظار الإصدار.

garthenweb هل يؤثر هذا على @sentry/node بسبب كيفية تطوير الحزمة؟ أحد المشاريع التي أقوم بتطويرها على hapi (ويعتمد على العديد من التبعيات الأخرى) لا ينتج عنه تسريبات (على الأقل لا يتم اكتشافها في المختبر ).

sunknudsen أكثر أو أقل. إنه مزيج من حزمة النطاق (المهملة) والوعود بقدر ما فهمت. راجع https://github.com/getsentry/sentry-javascript/blob/master/packages/node/src/handlers.ts#L233

في حالتي ، قمت للتو بإزالة البرامج الوسيطة الحارس من الخادم (السريع) لإصلاحها.

هذه ليست مشكلة في العقدة ولكن في Sentry حيث يؤدي تعطيل معالجات Sentry إلى حل المشكلة ؛

MartijnHols نحن نعمل حاليًا على إصدار رئيسي من شأنه أن يقلل بشكل كبير من أثر الذاكرة على SDK الخاص بنا. إذا كنت تشعر بالمغامرة ، يمكنك تجربتها https://github.com/getsentry/sentry-javascript/pull/1919

HazAT شكرًا ، لقد قمت بتثبيته في الإنتاج الليلة الماضية (الساعة 23:10 في الرسم البياني)

MartijnHols شكرا

شيئين يجب أخذهما في الاعتبار ، إصلاح تسرب الذاكرة للمجالات في العقدة هبط مؤخرًا فقط في 11.10 .
أيضًا ، كان علينا إلغاء نشر 5.0.0-beta1 لأنه تم وضع علامة عليه بالخطأ على أنه latest ، 5.0.0-rc.1 هو الآن أحدث إصدار next .
الرجاء تجربة 5.0.0-rc.1 لقد أجرينا تغييرًا بسيطًا على كيفية وضع الأحداث في قائمة الانتظار والتي من شأنها تحسين التحميل / الذاكرة كثيرًا.

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

LGTM. شكر!

سأكون سعيدًا لتجربة هذا أيضًا. HazAT هل تعرف ما إذا كان الإصلاح في 11.10 قد تم نقله بالفعل إلى إصدار LTS النشط 10.x ؟

adriaanmeuris لقد قرأت أن أحدهم سأل عما إذا كان سيتم نقله إلى 10.x ، لست متأكدًا مما إذا كان سيفعل ذلك.
المرجع: https://github.com/nodejs/node/pull/25993#issuecomment -463957701

لقد قمت بحل مشكلة إنشاء العميل والنطاق يدويًا في برمجيات وسيطة صريحة

لقد قمت بإنشاء ملف services/sentry بتصدير وظيفة

import {
  NodeClient as SentryClient, Hub, Integrations, Scope,
} from '@sentry/node';
import config from 'config';

const sentryClient = new SentryClient({
  ...config.sentry,
  frameContextLines: 0,
  integrations: [new Integrations.RewriteFrames()],
});

export default () => {
  const scope = new Scope();
  const client = new Hub(sentryClient, scope);
  return Object.freeze({ client, scope });
};

وفي البرامج الوسيطة ، أحفظ العميل / النطاق الحارس في كائن الطلب مثل هذا

app.use((req, res, next) => {
  req.sentry = getSentry();
  req.sentry.scope.setTag('requestId', req.requestId);
  req.sentry.scope.setExtra('More info', 'XXXXXX');
  next();
});
....
// and use the express error handler
app.use((err, req, res, next) => {
  const code = err.code || 500;
  res.status(code).json({
    code,
    error: err.message,
  });
  if (code >= 500) {
    req.sentry.client.captureException(err);
  }
  next();
});

مع هذا يبدو أن الذاكرة تسربت ثابتة

couds هذا التنفيذ رائع حقًا ، هناك شيء واحد عليك التفكير فيه.

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

HazAT شكرا ، وأنا أعلم ذلك ، ولكن هو ثمن قليل للدفع. لحل هذا التسرب الضخم للذاكرة ، ولكن لتقليل هذا الضياع ، قمت ببعض الأشياء.

1. أحاول التعامل مع جميع الاستثناءات التي أفضلها لعدم الاعتماد على أحداث unCoughException / الوعد.
2. بالنسبة إلى فتات التنقل ، أقوم بإضافتها يدويًا طالما أنه يمكنني الوصول إلى الكائن req ..
3. قم بتحميل خرائط المصادر إلى الحارس باستخدام @sentry/webpack-plugin
4. أضف علامات / إضافات على كل طلب للمساعدة في تحديد المشكلة

شيء آخر ، لقد نسيت لصق علامة أخرى أقوم بإضافتها وهي المعاملة (لمحاكاة المعالج الافتراضي)

req.sentry.scope.setTag('transaction', `${req.method}|${req.route ? req.route.path : req.path}`);

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

HazATkamilogorek اننا لا نزال نرى نمو الذاكرة كبير على [email protected] و [email protected] - هل أنت على يقين من أن هذا التصحيح nodejs ثابتة عليه؟

tpbowden هل يمكنك رجاءً تقديم نسخة أو على الأقل قول كيف تبدو شفرتك؟
أيضًا ، هل تستخدم أي مكونات إضافية متعلقة بـ Sentry؟

HazAT لقد حاولت إعادة الإنتاج ولكن السبب في ذلك هو خادم معقد إلى حد ما به الكثير من البرامج الوسيطة (عرض جانب الخادم React). مع تثبيت البرامج الوسيطة Sentry ، نحقق نموًا هائلاً في الذاكرة (في ظل الحمل الثقيل ، يمكن أن تزيد بمقدار 10 ميجابايت / ثانية تقريبًا). عندما نزيل البرامج الوسيطة Sentry.Handlers.requestHandler() من خادمنا ، تكون الذاكرة ثابتة عند 200 ميجابايت تقريبًا

نحن لا نستخدم أي مكونات إضافية ، فقط @sentry/node . هل يمكنك التفكير في أي شيء يمكنني محاولة مساعدته في إعادة إنتاج هذا؟

HazAT يبدو أنه مرتبط بتجميع Sentry باستخدام حزمة الويب على الخادم - يحدث فقط عندما يتم إنشاء التطبيق بواسطة Webpack. أدت إضافة @sentry/node إلى externals إلى إصلاح مشكلة الذاكرة لدينا. أي فكرة لماذا يحدث هذا؟

لا يزال التسرب قابلاً للتكرار على Node 11.14.0 باستخدام @ sentry / node 5.1.0

بالنسبة لنا ، يحدث التسرب بسبب التفاعل بين @ sentry / node و i18next-express-middleware. يشبه تطبيقنا السريع https://github.com/i18next/react-i18next/blob/master/example/razzle-ssr/src/server.js.

إذا وضعنا .use(Sentry.Handlers.requestHandler()); أعلى من .use(i18nextMiddleware.handle(i18n)) فسنحصل على تسرب للذاكرة. إذا وضعنا الحارس تحته ، فلن يحدث تسريب.

لدينا نفس المشكلة. لقد جربته باستخدام node 10.15.3 و 11.14.0 . إليك الحد الأدنى من المستودع لإعادة إنتاج المشكلة https://github.com/michalkvasnicak/sentry-memory-leak-reproduction. فقط قم بتشغيل yarn test أو yarn test:watch والذي سيبلغ عن استخدام الكومة. يزداد دائما.

yarn test

yarn test:watch

michalkvasnicak شكرًا على الوقت الذي

أنت لا تختبر حقًا أي شيء يتعلق بـ SDK

const Sentry = require('@sentry/node');

it('works', () => {
  expect(true).toBe(true);
});

أنت تطلب الحزمة ولكن هذا كل شيء.
لست متأكدًا بما أنه ليس لدي خبرة حتى الآن في إجراء اختبارات التسرب الجارية على jest ولكن ما الذي يمكن أن يتسرب بمجرد طلب الحزمة؟
لست متأكدًا ، ربما أفتقد شيئًا ما ولكني أتوقع أن تنمو الذاكرة عند تحميل حزمة جديدة.

فيما يتعلق بما يمكن أن يتسرب ، فإننا نخلق بعض المتغيرات العالمية لكننا نحتاجها لتتبع الحالة.

HazAT نعم هذا غريب ولكن يكفي أن تتسرب الاختبارات ، jest سيفشل مع اكتشاف التسريب. لدينا نفس المشكلة في قاعدة الشفرة الخاصة بنا حيث أدى مجرد التعليق على استيراد @sentry/node حل مشكلة التسرب.

michalkvasnicak لقد حققت في هذا الأمر ولم يكن السبب المباشر هو Sentry.

يعتمد النقل على @sentry/node على https-proxy-agent ، والذي يعتمد على agent-base والذي يتطلب ملف patch-core.js _ وهذا ما يؤدي إلى حدوث تسرب: تجاهل:

https://github.com/TooTallNate/node-agent-base/issues/22

يمكنك التحقق من ذلك بسهولة عن طريق نسخ محتواه في اختبارك وتشغيله باستخدام إحصائيات كومة:

const url = require("url");
const https = require("https");

https.request = (function(request) {
  return function(_options, cb) {
    let options;
    if (typeof _options === "string") {
      options = url.parse(_options);
    } else {
      options = Object.assign({}, _options);
    }
    if (null == options.port) {
      options.port = 443;
    }
    options.secureEndpoint = true;
    return request.call(https, options, cb);
  };
})(https.request);

https.get = function(options, cb) {
  const req = https.request(options, cb);
  req.end();
  return req;
};

it("works", () => {
  expect(true).toBe(true);
});

سيتعين علينا على الأرجح تفرعها أو كتابة حل بديل.

أي حل بديل لهذا؟

https://nodejs.org/en/blog/release/v10.16.0/

إصلاح بعض تسريبات الذاكرة ، هل يمكن لأحد اختبارها؟

لدي نفس المشكلة في العقدة 11.10 ، ولكن يبدو أنه تم إصلاحها على العقدة 12.3.1

هناك PR مفتوح للمشكلة agent-base : https://github.com/TooTallNate/node-agent-base/pull/25

يمكننا إما تفرع هذا وتجاوز التبعية في قرارات الغزل أو إيجاد طريقة لدمجها.

قد يكون بعيد المنال قليلاً ، ولكن قد يتسبب أيضًا في بعض التسريبات لعدم وجود تنظيف للمجال في Handlers.ts ، فقط domain.create؟
تقترح المقالة المتوسطة أو SO يجب أن يكون هناك removeListeners و domain.exit. لكنها لم تجد إجابة قاطعة على ذلك.

تحديث: الآن أرى أن المعالجات تستخدم domain.run الذي يستدعي domain.exit داخليًا. قد يؤدي الاستمرار في إزالة المستمعين / الباعثين إلى إحداث فرق ، لكن بصراحة ليس لديهم أي فكرة.

لقد قمت بالترقية إلى Node 12.4.0 وما زلت أرى سلوكًا سيئًا يبدو أنه مرتبط بـ Sentry.

إليك بعض عمليات التشغيل التي يقوم بها أطباء عيادة العقدة ، ويتم ذلك باستخدام خيار --autocannon على مدار 90 ثانية.

• بدون أي تهيئة الحارس
• مع init ولكن بدون معالجات الطلبات السريعة
• مع كل من المعالجات و init (إعداد الإنتاج الحالي لدينا)

يبدو فقط أنه يتسرب حقًا عندما تكون معالجات الطلب في مكانها الصحيح. إذا نظرت إلى قيعان أحواض GC في الجري بدون معالجات ، فجميعهم على نفس المستوى تقريبًا (65-70 ميجابايت) ، حيث يبدو أن الجري مع المعالجات يتسلق حوالي 5 ميجابايت مع كل دورة GC.

@ tstirrat15 لم يتم إصدار هذا الإصلاح بعد ، ولهذا السبب على الأرجح لا تزال تواجه هذه المشكلة. هل يمكنك المحاولة من أحدث معلم إذا كان هذا خيارًا؟

@ tstirrat15 5.4.2 مع الإصلاح المضمن تم إصداره ، جربه :)

إليك شوط آخر مع v5.4.2 في مكانه. لا يزال يبدو متسربًا بعض الشيء ...

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

حسنًا ... يبدو جيدًا. سأنقل هذا العلاقات العامة إلى الإنتاج وأرى ما إذا كان السلوك يتغير. شكرا جزيلا!

يبدو أنه مرتبط بتجميع Sentry باستخدام حزمة الويب على الخادم - يحدث فقط عندما يتم إنشاء التطبيق بواسطة Webpack. أدت إضافة @ sentry / node إلى العناصر الخارجية إلى إصلاح مشكلة الذاكرة لدينا. أي فكرة لماذا يحدث هذا؟

tpbowden أنت محق في هذا الأمر ، لدي نفس المشكلة. كنت أقوم بتشغيل SDK v5.15.0 و node v12.3.1 ، وكلاهما من المفترض أن يشتمل على جميع الإصلاحات المطلوبة المذكورة هنا.

أقوم بتجميع جميع التبعيات داخل حزمة الخادم الخاصة بي مع حزمة الويب. بهذه الطريقة يمكنني شحن صورة عامل إرساء بدون node_modules ، لكن هناك شيء ما يفسد SDK الحارس ويسرب الذاكرة عند تجميعها بهذه الطريقة.

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

أنا أستخدم أيضًا razzle.js المتأخر قليلاً في إصدارات webpack / terser ، ربما تم إصلاحه بالفعل.

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

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

ابقينا على اطلاع ، شكرا لك!

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

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

أو ربما يكون النطاق بأكمله هو الذي من المفترض أن يكون فريدًا ويتم جمع القمامة لكل طلب؟

هذا صحيح. ومع ذلك، scope يجب المستنسخة عن كل جديد domain المثال 🤔

انظر مكدس الاستدعاءات هذا:

https://github.com/getsentry/sentry-javascript/blob/fd26d9fa273002502706b03fc1a9a46864cd8440/packages/node/src/handlers.ts#L319 -L328

https://github.com/getsentry/sentry-javascript/blob/fd26d9fa273002502706b03fc1a9a46864cd8440/packages/hub/src/hub.ts#L442 -L457

https://github.com/getsentry/sentry-javascript/blob/fd26d9fa273002502706b03fc1a9a46864cd8440/packages/hub/src/hub.ts#L463 -L488

https://github.com/getsentry/sentry-javascript/blob/fd26d9fa273002502706b03fc1a9a46864cd8440/packages/hub/src/hub.ts#L479

ها! أعتقد أنني وجدت شيئا.

نحن نستخدم dynamicRequire:
https://github.com/getsentry/sentry-javascript/blob/fd26d9fa273002502706b03fc1a9a46864cd8440/packages/hub/src/hub.ts#L465-L468

ولكن عندما أخطو إلى كود dynamicRequire:
https://github.com/getsentry/sentry-javascript/blob/fd26d9fa273002502706b03fc1a9a46864cd8440/packages/utils/src/misc.ts#L28-L31

require غير محدد في mod 🤯

لذلك يدخل catch كتلة من getHubFromActiveDomain ظيفة وبدلا من استخدام getHubFromCarrier() !

نظرًا لأنه تم تجميع _everyting_ في الإعداد الخاص بي بواسطة حزمة الويب ، فمن المحتمل أن تكون هناك بعض الافتراضات التي تم إجراؤها على الكائن mod الذي تم كسره بواسطة webpack. هل لديك فكرة عن كيفية إصلاح هذا؟ 🤔

خلاصة

نحن نستخدم dynamicRequire:

mod.require غير محدد:

كيف يبدو كائن التعديل:

انتهى بنا الأمر باستخدام getHubFromCarrier:

لقد قمت يدويًا بتصحيح وحدة Hub مباشرة في مجلد node_modules الخاص بي. أزلت السطر باستخدام dynamicRequire وأضفت للتو import domain from 'domain'; في الجزء العلوي من الملف و ... يعمل الآن بشكل مثالي! لا مزيد من التسريبات! 🎉

ربما كانت هناك حاجة إلى اختراق dynamicRequire من قبل ، ولكن لم تعد هناك حاجة إليه مع الإصدارات الأحدث من webpack؟ 🤔

حاولت أيضًا استبدال:

const domain = dynamicRequire(module, 'domain');

مع:

const domain = require('domain');

كما أنه يعمل بشكل جيد. لا أعرف أي من هذين الحلين تفضل.

هل تريد مني أن أفتح علاقات عامة بهذا الإصلاح؟