Sentry-javascript: 10.13.0 노드에서 @ sentry / node 메모리 누수

@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가 메모리 문제를 관찰하지 않음)를 사용하여 예제를 실행하고 gatling testsuite를 사용하여 다음 리소스를 요청했습니다.

    "/",
    "/_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/

수천 번의 요청 후에 우리의 메모리 사용량은 거의 1GB였으며 유휴 상태에서도 줄어들지 않았습니다. server.js에서 요청과 errorHandler를 제거하자마자 메모리 누수가 중지됩니다. 그래서 그 2에 연결되어있는 것 같습니다. 요청이 너무 적거나 노드 8.x를 사용 했습니까?

@abraxxas가 확인되었습니다. 노드 10 + 각 리소스에 대해 ~ 300req가 작업을 수행합니다. 더 조사하겠습니다. 감사!

@kamilogorek intersting, 그러나 당신이 당신의 힙 크기를 보면
재생산 당신은 핸들러없이 약 20MB에 머무르는 것을 볼 수 있습니다
그러나 그들과 함께 빠르게 증가합니다.

핸들러가없는 메모리 누수 경고가 발생하는 이유는
요청으로 인해 일정한 메모리가 증가합니다.

버전간에 메모리 사용량에는 여전히 큰 차이가 있습니다.
보초 및없이.

2018 년 11 월 29 일 목요일 12:45 Kamil Ogórek < [email protected] 작성 :

@abraxxas https://github.com/abraxxas 성공적으로 재현했습니다.
그러나 서버는 여전히 자체적으로 요청 객체를 누출하는 것으로 보입니다.
Sentry 핸들러 없이도.

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 참조) 모든 것이 글로벌 상태에서 관리되고있는 것처럼 보이고 요청 종료

@abraxxas @tpbowden Node의 코어 자체에 도메인 모듈이 유출되는 문제가 있습니다. 우리는 그것을 계속 모니터링하고 코어에 고정되기 전에 임시 해결책을 마련하려고 노력할 것입니다. 관련 문제 : 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

단위 테스트를 위해 실험실 사용. 누출은 여전히 ​​존재합니다. 누수는 디버그하기가 힘들 수 있음을 알고 있습니다. 수정을위한 ETA가 있습니까?

1 개의 테스트 완료
테스트 기간 : 1832ms
다음 누수가 감지되었습니다 .__ extends, __assign, __rest, __decorate, __param, __metadata, __awaiter, __generator, __exportStar, __values, __read, __spread, __await, __asyncGenerator, __asyncDelegator, __asyncValues, __makeTemplateObject, __importStar, __importDefault

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에서 개발하고있는 (그리고 다른 많은 의존성에 의존하는) 프로젝트 중 하나는 누출을 일으키지 않습니다 (적어도 그들은 lab에서 잡히지 않습니다).

@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에) 아래 결과로 핸들러를 다시 활성화했습니다. 일반적으로 전날에서 볼 수 있듯이 23 : 00-24 : 00 경에 CPU 사용량이 약간 급증했지만 이보다 더 높은 것 같습니다. 표준 CPU 사용량은 핸들러가없는 것보다 훨씬 더 뾰족합니다. 이것이 새 버전의 변경으로 인한 것인지 아니면 활성화되는 핸들러인지 확실하지 않습니다. 몇 시간 후에 핸들러를 다시 비활성화 해 보겠습니다. 시간당 약 2.5 개의 오류가 발생합니다.

@MartijnHols 사용해 주셔서 감사합니다!

명심해야 할 두 가지 사항은 노드의 도메인에 대한 메모리 누수 수정이 최근에 11.10 도착한 것입니다.
또한 5.0.0-beta1 은 (는) 실수로 latest 로 태그가 지정 되었기 때문에 게시를 취소해야했습니다. 5.0.0-rc.1 이 이제 최신 next 버전입니다.
5.0.0-rc.1 시도해보십시오. 이벤트 대기열 방식을 약간 변경하여로드 / 메모리를 크게 향상 시켰습니다.

11.12 노드로 업데이트하면 메모리 및 CPU 사용량이 안정화 된 것 같습니다. 핸들러를 비활성화 한 것과 비교할 때 리소스 사용량에 눈에 띄는 차이가없는 것 같습니다. 또한 필요한 모든 정보로 오류를 잘 잡아내는 것 같습니다 (더 많은 콘솔 "breadcrumbs"가있을 수 있습니다). 5.0.0에서 무엇을 확인할 수 있는지 잘 모르겠습니다. 문제가 발생하면 알려 드리겠습니다.

LGTM. 감사!

나는 이것도 시도해 드리겠습니다. @HazAT 11.10 의 수정이 이미 활성 LTS 릴리스 10.x 백 포트되었는지 알고 있습니까?

@adriaanmeuris 누군가가 10.x 로 백 포트 될 것인지 물어 보았지만 , 그렇게 할 것인지 확실하지 않습니다.
참조 : https://github.com/nodejs/node/pull/25993#issuecomment -463957701

Express 미들웨어에서 클라이언트 및 범위를 수동으로 생성하는 문제를 해결했습니다.

함수를 내보내는 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 / promise 이벤트에 의존하지 않으려는 모든 예외를 처리하려고합니다.
2. 이동 경로의 경우 req 개체에 액세스 할 수있는 한 수동으로 추가합니다.
3. @sentry/webpack-plugin 하여 소스 맵을 센트리에 업로드합니다.
4. 문제를 식별하는 데 도움이되는 모든 요청에 ​​태그 / 추가 추가

한 가지 더, 트랜잭션 (기본 처리기를 시뮬레이션하기 위해)이라는 태그를 하나 더 붙여 넣는 것을 잊었습니다.

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

나는 이것이 누군가에게 도움이되기를 바랍니다. Sentry는 정말 훌륭한 도구이며 스택에서 제거하지 않도록 할 수있는 일을했습니다.

@HazAT @kamilogorek 우리는 여전히 [email protected] 및 [email protected] 에서 엄청난 메모리 증가를보고 있습니다-이 nodejs 패치가 문제를 해결했다고 확신하십니까?

@tpbowden 재현을 제공하거나 최소한 코드가 어떻게
또한 Sentry와 관련된 다른 플러그인을 사용하고 있습니까?

@HazAT 나는 재현하려고 시도했지만 많은 미들웨어가있는 상당히 복잡한 서버 (서버 측 렌더링 React)로 인해 발생합니다. Sentry 미들웨어가 설치된 상태에서 메모리가 엄청나게 증가하고 있습니다 (부하가 많을 경우 최대 10MB / 초까지 증가 할 수 있음). 서버에서 Sentry.Handlers.requestHandler() 미들웨어를 제거하면 메모리는 ~ 200MB로 일정합니다.

플러그인을 사용하지 않고 @sentry/node 만 사용합니다. 이것을 재현하는 데 도움이 될만한 것이 무엇인지 생각해 주시겠습니까?

@HazAT 서버에서 webpack을 사용하여 Sentry를 번들링하는 것과 관련이있는 것 같습니다. 앱이 Webpack에 의해 빌드 된 경우에만 발생합니다. @sentry/node 을 externals 추가하면 메모리 문제가 해결되었습니다. 왜 이런 일이 발생하는지 아십니까?

누출은 @ sentry / node 5.1.0을 사용하여 Node 11.14.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 파일이 필요합니다 _and_ 이것이 누수를 생성하는 것입니다.

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에서 수정 된 것 같습니다.

agent-base 문제에 대한 PR이 열려 있습니다 : https://github.com/TooTallNate/node-agent-base/pull/25

우리는 이것을 포크하고 Yarn 해상도에서 종속성을 재정의하거나 병합하는 방법을 찾을 수 있습니다.

주제에서 약간 벗어난 것일 수 있지만 Handlers.ts에 도메인 정리가없고 domain.create 만 존재하는 일부 유출이 발생할 수도 있습니다.
중간 기사 또는 SO 는 removeListeners 및 domain.exit가 있어야한다고 제안합니다. 그러나 그것에 대한 확실한 답을 찾지 못했습니다.

업데이트 : 이제 처리기가 내부적으로 domain.exit를 호출하는 domain.run을 사용하고 있음을 알 수 있습니다. 여전히 리스너 / 이미 터를 제거하면 차이가 생길 수 있지만 솔직히 알 수 없습니다.

Node 12.4.0으로 업그레이드했는데 여전히 Sentry와 관련된 것처럼 보이는 나쁜 동작이 보입니다.

다음은 90 초 동안 --autocannon 옵션을 사용하여 수행 된 노드 클리닉 의사 실행입니다.

• 센트리 초기화없이
• init 급행 요청 핸들러 없음)
• 핸들러와 init (현재 프로덕션 설정)

요청 처리기가 제자리에있을 때만 실제로 누출되는 것처럼 보입니다. 핸들러가없는 실행에서 GC 최저점을 보면 모두 거의 동일한 수준 (65-70mb)에 있으며 핸들러를 사용한 실행은 각 GC주기에서 약 5mb가 상승하는 것처럼 보입니다.

@ tstirrat15 이 수정 사항은 아직 릴리스되지 않았

@ tstirrat15 5.4.2 수정 사항이 포함 된 버전이 출시되었습니다. 한번 시도해보세요. :)

다음은 v5.4.2가 적용된 또 다른 실행 입니다. 아직도 약간 새는 것 같습니다 ...

GC는 항상 올바르게 시작되며 메모리를 기준선으로 복원합니다. 메모리 사용량 증가는 이벤트 및 이벤트 큐에서 수집 된 이동 경로로 인해 발생하지만 이동 경로가 100 개에서 중지되고 더 이상 증가하지 않습니다. ~ 15-30 분 덤프와 같은 것을 볼 수 있고 피크 메모리가 어느 시점에서 멈추는 지 여부를 볼 수 있다면 좋을 것입니다.

흠 ... 좋은 것 같네요. 이 PR을 프로덕션에 전달하고 동작이 변경되는지 확인합니다. 감사합니다!

서버에서 webpack을 사용하여 Sentry를 번들링하는 것과 관련이있는 것 같습니다. 앱이 Webpack에 의해 빌드 된 경우에만 발생합니다. @ sentry / node를 외부에 추가하면 메모리 문제가 해결되었습니다. 왜 이런 일이 발생하는지 아십니까?

@tpbowden 당신이 맞아요, 저도 같은 문제가 있습니다. 나는 SDK v5.15.0과 node v12.3.1을 실행하고 있었는데, 둘 다 여기에 언급 된 모든 필수 수정 사항을 포함해야했습니다.

내 서버 번들 내의 모든 종속성을 webpack과 번들로 묶습니다. 이렇게하면 node_modules없이 도커 이미지를 배송 할 수 있지만 무언가 센트리 SDK를 엉망으로 만들고 이런 방식으로 번들로 묶으면 메모리가 누출됩니다.

일부 최적화 프로세스로 인해 발생한 버그 일 수 있습니다. 내 추측은 아마 더 간결하다는 것입니다. 일부 최적화는 아마도 도메인 모듈의 사용을 엉망으로 만들고 scope.addEventProcessor 로 전달 된 콜백의 폐쇄는 더 이상 가비지 수집되지 않으므로 모든 요청은 상당한 양의 메모리를 누출합니다.

나는 또한 webpack / terser 버전에서 약간 뒤쳐진 razzle.js를 사용하고 있습니다. 아마도 이미 수정되었을 것입니다.

이것은 더 이상 센트리 측의 버그가 아닌 것 같습니다. 계속해서이 문제를 조사하고 적절한 경우 문제를 열고이 스레드를 계속 업데이트 할 것입니다.

이것은 더 이상 센트리 측의 버그가 아닌 것 같습니다. 계속해서이 문제를 조사하고 적절한 경우 문제를 열고이 스레드를 계속 업데이트 할 것입니다.

계속 게시 해주세요. 감사합니다!

@kamilogorek Scope 인스턴스 내의 _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 에 정의되지 않았습니다. 🤯

따라서 getHubFromActiveDomain 함수의 catch 블록을 입력하고 대신 getHubFromCarrier() !

내 설정에서 _everyting_은 webpack에 번들로 제공되므로 mod 개체에 대한 가정이 웹팩에 의해 손상되었을 수 있습니다. 이 문제를 해결하는 방법에 대한 아이디어가 있습니까? 🤔

요약

dynamicRequire를 사용합니다.

mod.require가 정의되지 않았습니다.

mod 객체의 모습 :

결국 getHubFromCarrier를 사용합니다.

node_modules 폴더에서 직접 허브 모듈을 수동으로 패치했습니다. dynamicRequire 사용하여 줄을 제거하고 파일 맨 위에 import domain from 'domain'; 를 추가했습니다. 이제 완벽하게 작동합니다! 더 이상 누출이 없습니다! 🎉

이전에는 dynamicRequire 해킹이 필요했지만 최신 버전의 웹팩에서는 더 이상 필요하지 않을까요? 🤔

나는 또한 교체하려고 시도했다 :

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

와:

const domain = require('domain');

그리고 그것은 또한 잘 작동합니다. 이 두 가지 솔루션 중 어떤 것을 선호할지 모르겠습니다.

이 수정으로 PR을 열겠습니까?