Sentry-javascript: @ Sentry / Node Speicherlecks auf Knoten 10.13.0

@abraxxas Können Sie mir helfen, dieses Problem zu reproduzieren? Wie genau lösen Sie dieses Memleak aus?
Ich habe Ihre Beschreibung ohne Glück versucht, sie erzeugt nur Statistikereignisse, niemals eine.

@kamilogorek Danke für deine Antwort. Was ich getan habe, war das Folgende. Ich habe dieses Beispiel https://github.com/sheerun/next.js/tree/with-sentry-fix/examples/with-sentry ausgecheckt und memwatch zur server.js hinzugefügt

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));
  });
}

Dann habe ich das Beispiel mit Knoten 10.x ausgeführt (wobei 8.xi keine Speicherprobleme festgestellt hat) und mithilfe unserer Gatling-Testsuite die folgenden Ressourcen angefordert:

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

(Beachten Sie, dass sich die Hashes für Sie ändern können.)

Sie sollten jedoch in der Lage sein, mit diesem Ansatz die gleichen Ergebnisse zu erzielen. https://www.simonholywell.com/post/2015/06/parallel-benchmark-many-urls-with-apachebench/

Nach einigen tausend Anfragen lag unsere Speichernutzung bei fast 1 GB und wurde auch im Leerlauf nie reduziert. Sobald ich die Anfrage und den errorHandler von server.js entferne, stoppt der Speicherverlust. Es scheint also mit diesen 2 verbunden zu sein. Vielleicht hatten Sie entweder zu wenige Anfragen oder haben Knoten 8.x verwendet?

@abraxxas bestätigt. Knoten 10 + ~ 300 req für jede Ressource erledigt den Job. Wird weiter untersuchen. Vielen Dank!

@kamilogorek interessant , aber wenn Sie auf die Haufengröße in Ihrem schauen
Reproduktion Sie werden sehen, dass es ohne die Handler etwa 20 MB bleibt
aber nimmt mit ihnen schnell zu.

Ich denke, die Speicherverlustwarnung ohne die Handler geschieht nur, weil
Aufgrund der Anforderungen kommt es zu einer gewissen Speichererweiterung.

Es gibt immer noch einen großen Unterschied in der Speichernutzung zwischen der Version mit
Wachposten und ohne.

Am Do, 29. November 2018, 12:45 Uhr schrieb Kamil Ogórek < [email protected] :

@abraxxas https://github.com/abraxxas Ich habe es erfolgreich reproduziert,
Es scheint jedoch, dass der Server immer noch selbst Anforderungsobjekte verliert.
auch ohne Sentry-Handler.

https://streamable.com/bad9j

Die Wachstumsrate ist etwas höher, da wir die Domain und unseren eigenen Umfang anhängen
Objekt gegen die Anfrage, aber es würde zusammen mit der Anfrage von GC verwendet werden.

- -
Sie erhalten dies, weil Sie erwähnt wurden.
Antworte direkt auf diese E-Mail und sieh sie dir auf GitHub an
https://github.com/getsentry/sentry-javascript/issues/1762#issuecomment-442804709 ,
oder schalten Sie den Thread stumm
https://github.com/notifications/unsubscribe-auth/AIbrNlgPjPd5Jra1aahR-Dthf7XvbCexks5uz8jjgaJpZM4YvOA2
.

@abraxxas ignoriere meinen vorherigen Kommentar (den, den ich entfernt habe), er ist total auf unserer Seite :)

Es scheint das Problem im Kern von Node selbst zu sein. Bitte beziehen Sie sich auf diesen Kommentar https://github.com/getsentry/sentry-javascript/issues/1762#issuecomment -444126990

@kamilogorek Hattest du schon Gelegenheit, dies zu untersuchen? Es verursacht einen großen Speicherverlust für uns. Nach dem Betrachten des Haufens sieht diese Zeile so aus, als könnte sie die Wurzel des Problems sein:

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

Der Inspektor zeigte Tausende von Einträgen in die Liste eventProcessors

Ich habe keinen Kontext darüber, wie Dinge aufgebaut sind, aber wir haben festgestellt, dass Anforderungen nicht korrekt sind und die falschen Metadaten enthalten (siehe # 1773), sodass anscheinend alles im globalen Status verwaltet und nicht bereinigt wird, wenn a Anfrage endet

@abraxxas @tpbowden Es gibt ein Problem mit undichten Domänenmodulen im Kern des Knotens. Wir werden es weiter überwachen und versuchen, eine temporäre Lösung zu finden, bevor sie im Kern behoben wird. Zugehöriges Problem: https://github.com/nodejs/node/issues/23862

@kamilogorek Haben Sie Ideen für eine Problemumgehung oder eine vorübergehende Lösung dafür? Der Fortschritt beim Knotenproblem sieht ziemlich langsam aus

Wir verwenden derzeit PM2 , um Node.js Prozesse neu zu starten, wenn der Speicher einen bestimmten Schwellenwert erreicht. https://pm2.io/doc/en/runtime/features/memory-limit/#max -memory-Threshold-Auto-Reload

Verwenden des Labors für Unit-Tests. Die Lecks sind noch vorhanden. Ich weiß, dass das Debuggen von Lecks schmerzhaft sein kann. Gibt es eine ETA für eine Lösung?

1 Tests abgeschlossen
Testdauer: 1832 ms
Die folgenden Lecks wurden festgestellt: __ erweitert, __zuweisen, __rest, __decorate, __param, __metadata, __awaiter, __generator, __exportStar, __values, __read, __spread, __await, __asyncGenerator, __asyncDelegator, __asyncValues, __makeTemplateObject, __import

npm ERR! Code ELIFECYCLE
npm ERR! errno 1
npm ERR! [email protected] test: lab build/test
npm ERR! Beenden Sie den Status 1
npm ERR!
npm ERR! Fehler beim Test-Skript
npm ERR! Dies ist wahrscheinlich kein Problem mit npm. Es gibt wahrscheinlich zusätzliche Protokollierungsausgabe oben.

npm ERR! Ein vollständiges Protokoll dieses Laufs finden Sie in:
npm ERR! /Users/sunknudsen/.npm/_logs/2019-02-13T14_41_28_595Z-debug.log

@sunknudsen Das Problem wurde tatsächlich in NodeJS behoben, siehe https://github.com/nodejs/node/issues/23862 und https://github.com/nodejs/node/pull/25993. Wir müssen wahrscheinlich auf eine Veröffentlichung warten.

@garthenweb Betrifft dies @sentry/node aufgrund der Entwicklung des Pakets? Eines der Projekte, die ich auf Hapi entwickle (und auf vielen anderen Abhängigkeiten beruht), erzeugt keine Lecks (zumindest werden sie nicht vom Labor erfasst ).

@sunknudsen Mehr oder weniger. Soweit ich verstanden habe, ist es die Kombination aus (veraltetem) Domain-Paket und Versprechen. Siehe https://github.com/getsentry/sentry-javascript/blob/master/packages/node/src/handlers.ts#L233

In meinem Fall habe ich gerade die Sentry Middleware von meinem (Express-) Server entfernt, um das Problem zu beheben.

Dies ist kein Problem im Knoten, sondern in Sentry, da das Deaktivieren der Sentry-Handler das Problem behebt.

@MartijnHols Wir arbeiten derzeit an einer Hauptversion, die den Speicherbedarf unseres SDK erheblich reduzieren soll. Wenn Sie sich abenteuerlustig fühlen, können Sie es unter https://github.com/getsentry/sentry-javascript/pull/1919 ausprobieren

@HazAT Danke, ich habe es letzte Nacht in der Produktion installiert (um 23:10

@MartijnHols Danke, dass ausprobiert hast !

Zwei Dinge, die Sie beachten sollten: Die Speicherleck-Korrektur für Domänen im Knoten ist erst kürzlich in 11.10 im Knoten gelandet.
Außerdem mussten wir die Veröffentlichung von 5.0.0-beta1 aufheben, da es fälschlicherweise als latest markiert wurde. 5.0.0-rc.1 ist jetzt die neueste Version von next .
Bitte versuchen Sie es mit 5.0.0-rc.1 Wir haben eine kleine Änderung vorgenommen, wie Ereignisse in die Warteschlange gestellt werden, um die Auslastung / den Speicher erheblich zu verbessern.

Das Update auf Knoten 11.12 scheint die Speicher- und CPU-Auslastung stabilisiert zu haben. Es scheint, dass es derzeit keinen erkennbaren Unterschied in der Ressourcennutzung gibt, wenn man sie mit der Deaktivierung der Handler vergleicht, vielleicht sogar etwas besser. Es scheint auch Fehler mit allen Informationen zu fangen, die ich brauche (es könnte mehr Konsole "Breadcrumbs" haben, was nett ist). Ich bin mir nicht sicher, was ich sonst noch für 5.0.0 überprüfen kann. Ich werde Sie wissen lassen, wenn ich auf Probleme stoße, aber wahrscheinlich nicht.

LGTM. Vielen Dank!

Ich würde es auch gerne versuchen. @HazAT wissen Sie, ob der Fix in 11.10 bereits auf die aktive LTS-Version 10.x zurückportiert wurde ?

@adriaanmeuris Ich habe gelesen, dass jemand gefragt hat, ob es auf 10.x zurückportiert wird, nicht sicher, ob er es tun wird.
Ref: https://github.com/nodejs/node/pull/25993#issuecomment -463957701

Ich habe das Problem beim manuellen Erstellen von Client und Scope in einer Express-Middleware gelöst

Ich habe eine Datei services/sentry , die eine Funktion exportiert

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 });
};

und in einer Middleware speichere ich den Sentry-Client / Bereich auf dem Anforderungsobjekt wie folgt

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();
});

Damit scheint der Speicherverlust behoben zu sein

@couds Diese Implementierung ist wirklich nett, es gibt eine Sache, die Sie beachten müssen.

Für jede Anfrage erhalten Sie einen neuen Client und wir fangen keine globalen Fehler / automatischen Breadcrumbs (oder was auch immer die Standardintegrationen tun).

@HazAT Danke, das weiß ich, aber es ist ein kleiner Preis zu zahlen. Um diesen riesigen Speicherverlust zu beheben, aber um diesen Verlust zu minimieren, habe ich ein paar Dinge getan.

1. Ich versuche, alle Ausnahmen zu behandeln, die ich bevorzuge, um mich nicht auf die Ereignisse unCoughException / versprechen zu verlassen.
2. Für Breadcrumbs füge ich sie manuell hinzu, solange ich Zugriff auf das req-Objekt habe.
3. Laden Sie die Quellkarten mit @sentry/webpack-plugin den Wachposten hoch
4. Fügen Sie bei jeder Anfrage Tags / Extra hinzu, um das Problem zu identifizieren

Eine weitere Sache, ich habe vergessen, ein weiteres Tag einzufügen, das ich hinzufüge, nämlich die Transaktion (um den Standard-Handler zu simulieren).

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

Ich hoffe, dies hilft jemandem, Sentry ist ein wirklich großartiges Tool und ich habe alles getan, um zu vermeiden, dass es von meinem Stapel entfernt wird.

@HazAT @kamilogorek Wir sehen immer noch das enorme Speicherwachstum bei [email protected] und [email protected] - sind Sie sicher, dass dieser NodeJS-Patch das Problem behoben hat?

@tpbowden Kannst du bitte einen Repro bereitstellen ODER zumindest sagen, wie dein Code aussieht?
Verwenden Sie auch andere Plugins für Sentry?

@HazAT Ich habe versucht zu reproduzieren, aber es wird von einem ziemlich komplexen Server mit viel Middleware verursacht (serverseitiges Rendering React). Mit der installierten Sentry-Middleware verzeichnen wir ein enormes Speicherwachstum (unter hoher Last kann es um ~ 10 MB / Sekunde zunehmen). Wenn wir Sentry.Handlers.requestHandler() Middleware von unserem Server entfernen, ist der Speicher konstant bei ~ 200 MB

Wir verwenden keine Plugins, nur @sentry/node . Können Sie sich etwas vorstellen, mit dem ich versuchen könnte, dies zu reproduzieren?

@HazAT Es sieht so aus, als ob es mit der Bündelung von Sentry mithilfe von Webpack auf dem Server zusammenhängt - geschieht nur, wenn die App von Webpack erstellt wurde. Das Hinzufügen von @sentry/node zu externals hat unser Speicherproblem behoben. Irgendeine Idee, warum das passiert?

Das Leck ist auf Knoten 11.14.0 mit @ sentry / node 5.1.0 weiterhin reproduzierbar

Für uns wird das Leck durch das Zusammenspiel von @ sentry / node und i18next-express-middleware verursacht. Unsere Express-App ähnelt https://github.com/i18next/react-i18next/blob/master/example/razzle-ssr/src/server.js.

Wenn wir .use(Sentry.Handlers.requestHandler()); über .use(i18nextMiddleware.handle(i18n)) wir einen Speicherverlust. Wenn wir einen Wachposten darunter stellen, bekommen wir kein Leck.

Wir haben das gleiche Problem. Ich habe es mit node 10.15.3 und 11.14.0 versucht. Hier ist ein minimales Repository, um das Problem zu reproduzieren: https://github.com/michalkvasnicak/sentry-memory-leak-reproduction. Führen Sie einfach yarn test oder yarn test:watch , um die Heap-Nutzung zu melden. Es nimmt immer zu.

yarn test

yarn test:watch

@michalkvasnicak Danke, dass

Sie testen nicht wirklich etwas in Bezug auf das SDK

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

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

Sie benötigen das Paket, aber das war's.
Ich bin mir nicht sicher, da ich noch keine Erfahrung mit jest Ausführen von Lecktests habe. Aber was kann lecken, wenn ich nur das Paket benötige?
Ich bin mir nicht sicher, vielleicht fehlt mir etwas, aber ich würde erwarten, dass der Speicher beim Laden eines neuen Pakets wächst.

In Bezug auf das, was auslaufen kann, erstellen wir einige globale Variablen, aber wir benötigen sie, um den Status zu verfolgen.

@HazAT Ja, es ist seltsam, aber es reicht aus, um Tests zu lecken. jest schlägt fehl, wenn ein Leck erkannt wird. Wir haben das gleiche Problem in unserer Codebasis, bei dem nur das Kommentieren des Imports von @sentry/node das Problem mit dem Leck gelöst hat.

@michalkvasnicak Ich habe dies untersucht und es wird nicht direkt von Sentry verursacht.

Unser @sentry/node Transport hat eine Abhängigkeit von https-proxy-agent , die eine Abhängigkeit von agent-base die die Datei patch-core.js erforderlich ist. _Und dies erzeugt ein Leck: Achselzucken:

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

Sie können dies leicht überprüfen, indem Sie den Inhalt in Ihren Test kopieren und mit einer Heap-Statistik ausführen:

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);
});

Wir müssen es wahrscheinlich teilen oder eine Problemumgehung schreiben.

Gibt es eine Problemumgehung für diesen?

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

Einige Speicherlecks wurden behoben. Kann jemand sie testen?

Ich habe das gleiche Problem auf Knoten 11.10, aber es scheint auf Knoten 12.3.1 behoben zu sein

Für das Problem agent-base ist eine PR geöffnet: https://github.com/TooTallNate/node-agent-base/pull/25

Wir können dies entweder aufteilen und die Abhängigkeit in Garnauflösungen überschreiben oder einen Weg finden, sie zusammenzuführen.

Könnte ein bisschen offtopic sein, könnte aber auch einige Lecks verursachen, dass es keine Domain-Bereinigung in Handlers.ts gibt, nur domain.create?
Ein mittlerer Artikel oder SO schlägt vor, dass removeListeners und domain.exit vorhanden sein sollten. Aber ich habe keine endgültige Antwort darauf gefunden.

UPDATE: Jetzt sehe ich, dass Handler domain.run verwenden, das intern domain.exit aufruft. Das Entfernen der Listener / Emitter könnte einen Unterschied machen, hat aber ehrlich gesagt keine Ahnung.

Ich habe ein Upgrade auf Node 12.4.0 durchgeführt und sehe immer noch schlechtes Verhalten, das an Sentry gebunden zu sein scheint.

Hier sind einige Knotenklinik-Arztläufe, die mit der Option --autocannon über 90 Sekunden durchgeführt wurden.

• Ohne Wachinitialisierung
• Mit init aber ohne Express Request Handler
• Mit beiden Handlern und init (unser aktuelles Produktionssetup)

Es scheint nur dann wirklich undicht zu sein, wenn die Anforderungshandler vorhanden sind. Wenn Sie sich die Böden der GC-Täler im Lauf ohne die Handler ansehen, sind sie alle ungefähr auf dem gleichen Niveau (65-70 MB), wobei der Lauf mit den Handlern mit jedem GC-Zyklus ungefähr 5 MB zu steigen scheint.

@ tstirrat15 Dieses

@ tstirrat15 5.4.2 mit dem enthaltenen Fix wurde veröffentlicht, probieren Sie es aus :)

Hier ist ein weiterer Lauf mit Version 5.4.2. Es scheint immer noch ein bisschen undicht ...

GC wird immer korrekt aktiviert und stellt den Speicher auf der Basislinie wieder her. Die Erhöhung der Speichernutzung wird durch Breadcrumbs verursacht, die aus den Ereignissen und der Ereigniswarteschlange gesammelt wurden. Sie wird jedoch bei 100 Breadcrumbs gestoppt und steigt nicht weiter an. Es wäre schön, wenn wir sehen könnten, wie ~ 15-30min Dump und ob der Spitzenspeicher irgendwann stoppt.

Hmm ... hört sich gut an. Ich werde diese PR in die Produktion bringen und sehen, ob sich das Verhalten ändert. Dankeschön!

Es sieht so aus, als ob es mit der Bündelung von Sentry mithilfe von Webpack auf dem Server zusammenhängt. Dies geschieht nur, wenn die App von Webpack erstellt wurde. Das Hinzufügen von @ sentry / node zu externen Geräten hat unser Speicherproblem behoben. Irgendeine Idee, warum das passiert?

@tpbowden Sie haben Recht, ich habe das gleiche Problem. Ich habe das SDK v5.15.0 und den Knoten v12.3.1 ausgeführt, die beide alle hier genannten erforderlichen Korrekturen enthalten sollen.

Ich bündle alle Abhängigkeiten in meinem Server-Bundle mit Webpack. Auf diese Weise kann ich ein Docker-Image ohne node_modules versenden, aber etwas bringt das Sentry-SDK durcheinander und es verliert Speicher, wenn es auf diese Weise gebündelt wird.

Es könnte ein Fehler sein, der durch einen Optimierungsprozess verursacht wurde. Meine wilde Vermutung ist, dass es wahrscheinlich kürzer ist. Einige Optimierungen bringen wahrscheinlich die Verwendung des Domänenmoduls durcheinander, und das Schließen des an scope.addEventProcessor Rückrufs wird nicht mehr als Müll gesammelt, sodass bei jeder Anforderung eine große Menge an Speicher verloren geht.

Ich benutze auch razzle.js, was bei den Webpack / Terser-Versionen etwas zurückliegt, vielleicht ist es bereits behoben.

Dies scheint kein Fehler mehr auf der Seite des Wachmanns zu sein. Ich werde dies weiter untersuchen und gegebenenfalls ein Problem eröffnen und diesen Thread auf dem neuesten Stand halten.

Dies scheint kein Fehler mehr auf der Seite des Wachmanns zu sein. Ich werde dies weiter untersuchen und gegebenenfalls ein Problem eröffnen und diesen Thread auf dem neuesten Stand halten.

Halten Sie uns auf dem Laufenden, danke!

@kamilogorek Können Sie mir zeigen, wo im Code der Rückruf des Ereignisprozessors, der dem Array _eventProcessors in der Scope-Instanz hinzugefügt wurde, entfernt wird? Ich kann es nicht finden. Es scheint, dass alle Anforderungen diesem Array einen Ereignisprozessor-Rückruf hinzufügen und niemals entfernt werden. Wenn ich wissen würde, wie sie entfernt werden sollen, könnte es mir helfen, den Fehler besser zu verstehen.

Oder ist es vielleicht der gesamte Bereich, der für jede Anfrage eindeutig sein und Müll sammeln soll? Es scheint, dass jede Anforderung dieselbe Bereichsinstanz erhält 🤔

Oder ist es vielleicht der gesamte Bereich, der für jede Anfrage eindeutig sein und Müll sammeln soll?

Das ist richtig. scope sollte jedoch für jede neue domain Instanz oned geklont werden

Siehe diesen Aufrufstapel:

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

Ha! Ich glaube ich habe etwas gefunden.

Wir verwenden dynamicRequire:
https://github.com/getsentry/sentry-javascript/blob/fd26d9fa273002502706b03fc1a9a46864cd8440/packages/hub/src/hub.ts#L465-L468

Aber wenn ich in den dynamicRequire-Code gehe:
https://github.com/getsentry/sentry-javascript/blob/fd26d9fa273002502706b03fc1a9a46864cd8440/packages/utils/src/misc.ts#L28-L31

require ist auf mod 🤯 undefiniert

Es wird also in den catch -Block der getHubFromActiveDomain -Funktion eingegeben und stattdessen getHubFromCarrier() !

Da in meinem Setup _everyting_ von Webpack gebündelt wird, werden wahrscheinlich einige Annahmen für das mod -Objekt getroffen, das von Webpack beschädigt wird. Haben Sie eine Idee, wie dies behoben werden könnte? 🤔

Rekapitulieren

Wir verwenden dynamicRequire:

mod.require ist undefiniert:

Wie das Mod-Objekt aussieht:

Am Ende verwenden wir getHubFromCarrier:

Ich habe das Hub-Modul manuell direkt in meinem Ordner node_modules gepatcht. Ich habe die Zeile mit dynamicRequire und gerade import domain from 'domain'; oben in die Datei eingefügt und ... es funktioniert jetzt perfekt! Keine Lecks mehr! 🎉

Vielleicht wurde der dynamicRequire-Hack schon einmal benötigt, wird aber bei neueren Versionen von Webpack nicht mehr benötigt? 🤔

Ich habe auch versucht zu ersetzen:

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

mit:

const domain = require('domain');

und es funktioniert auch gut. Ich weiß nicht, welche dieser beiden Lösungen Sie bevorzugen würden.

Möchten Sie, dass ich mit diesem Fix eine PR eröffne?