Sentry-javascript: @ kebocoran memori sentry / node pada node 10.13.0

@abraxxas dapatkah Anda membantu saya mereproduksi masalah ini? Bagaimana tepatnya Anda memicu memleak ini?
Saya mencoba deskripsi Anda tanpa hasil, itu hanya menghasilkan peristiwa statistik, tidak pernah membocorkannya.

@kamilogorek Terima kasih atas tanggapan Anda. Apa yang saya lakukan adalah sebagai berikut. Saya memeriksa contoh ini https://github.com/sheerun/next.js/tree/with-sentry-fix/examples/with-sentry dan menambahkan memwatch ke 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));
  });
}

kemudian saya menjalankan contoh menggunakan node 10.x (dengan 8.xi mengamati tidak ada masalah memori) dan meminta sumber daya berikut menggunakan gatling testsuite kami:

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

(perhatikan hash mungkin berubah untuk Anda)

tetapi Anda harus dapat mencapai hasil yang sama dengan pendekatan ini dengan sangat sederhana https://www.simonholywell.com/post/2015/06/parallel-benchmark-many-urls-with-apachebench/

setelah beberapa ribu permintaan, penggunaan memori kami hampir mencapai 1GB dan tidak pernah berkurang bahkan saat idle. Segera setelah saya menghapus permintaan dan errorHandler dari server.js kebocoran memori berhenti. Jadi sepertinya terhubung ke 2. Mungkin Anda memiliki terlalu sedikit permintaan atau menggunakan node 8.x?

@abraxxas dikonfirmasi. Node 10 + ~ 300req untuk setiap resource melakukan tugasnya. Akan menyelidiki lebih lanjut. Terima kasih!

@kamilogorek menarik , tetapi jika Anda melihat heapsize di
reproduksi Anda akan melihat bahwa itu tetap sekitar 20mb tanpa penangan
tetapi meningkat pesat dengan mereka.

Saya pikir peringatan kebocoran memori tanpa penangan terjadi hanya karena
karena permintaan tersebut ada beberapa peningkatan memori constsnt.

Masih terdapat perbedaan yang sangat besar dalam penggunaan memori antara versi dengan
penjaga dan tanpa.

Pada Kamis, 29 Nov 2018, 12:45 Kamil Ogórek < [email protected] menulis:

@abraxxas https://github.com/abraxxas Saya berhasil mereproduksinya,
namun, tampaknya server masih membocorkan objek permintaannya sendiri,
bahkan tanpa penangan Sentry.

https://streamable.com/bad9j

Tingkat pertumbuhannya sedikit lebih besar, karena kami memasang domain dan cakupan kami sendiri
menolak permintaan tersebut, tetapi akan digunakan bersama permintaan oleh GC.

-
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/getsentry/sentry-javascript/issues/1762#issuecomment-442804709 ,
atau nonaktifkan utasnya
https://github.com/notifications/unsubscribe-auth/AIbrNlgPjPd5Jra1aahR-Dthf7XvbCexks5uz8jjgaJpZM4YvOA2
.

@abraxxas mengabaikan komentar saya sebelumnya (yang saya hapus), itu benar-benar di pihak kita :)

Tampaknya menjadi masalah di inti Node itu sendiri. Silakan merujuk ke komentar ini https://github.com/getsentry/sentry-javascript/issues/1762#issuecomment -444126990

@kamilogorek Pernahkan Anda melihat hal ini? Ini menyebabkan kebocoran memori yang sangat besar bagi kami. Setelah melihat heap, baris ini sepertinya bisa menjadi akar masalah:

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

Inspektur menunjukkan ribuan entri ke dalam daftar eventProcessors

Saya tidak memiliki konteks apa pun tentang bagaimana segala sesuatunya dirancang, tetapi kami telah memperhatikan bahwa permintaan tidak dicakup dengan benar dan memberikan metadata yang salah (lihat # 1773) sehingga tampaknya semuanya dikelola dalam keadaan global dan tidak dibersihkan ketika a permintaan berakhir

@abraxxas @tpbowden ada masalah dengan modul domain bocor di inti Node itu sendiri. Kami akan terus memantaunya dan mencoba memberikan solusi sementara sebelum diperbaiki pada intinya. Masalah terkait: https://github.com/nodejs/node/issues/23862

@kamilogorek apakah Anda punya ide untuk solusi atau perbaikan sementara untuk ini? Kemajuan masalah node terlihat cukup lambat

Kami saat ini menggunakan PM2 untuk memulai ulang proses Node.js saat memori mencapai ambang tertentu. https://pm2.io/doc/en/runtime/features/memory-limit/#max -memory-threshold-auto-reload

Menggunakan lab untuk pengujian unit. Bocorannya masih ada. Saya tahu kebocoran bisa menyakitkan untuk di-debug. Apakah ada ETA untuk perbaikan?

1 tes selesai
Durasi tes: 1832 ms
Kebocoran berikut terdeteksi: __ extends, __assign, __rest, __decorate, __param, __metadata, __awaiter, __generator, __exportStar, __values, __read, __spread, __await, __asyncGenerator, _asyncDelegarTalu, __asyort_sttStar, __asyort

npm ERR! kode ELIFECYCLE
npm ERR! errno 1
npm ERR! [email protected] tes: lab build/test
npm ERR! Status keluar 1
npm ERR!
npm ERR! Gagal di skrip uji [email protected] .
npm ERR! Ini mungkin bukan masalah dengan npm. Kemungkinan ada hasil penebangan tambahan di atas.

npm ERR! Log lengkap proses ini dapat ditemukan di:
npm ERR! /Users/sunknudsen/.npm/_logs/2019-02-13T14_41_28_595Z-debug.log

@sunknudsen Masalah sebenarnya telah diperbaiki di NodeJS, lihat https://github.com/nodejs/node/issues/23862 dan https://github.com/nodejs/node/pull/25993. Kami mungkin perlu menunggu rilis.

@garthenweb Apakah ini mempengaruhi @sentry/node karena bagaimana paket itu dikembangkan? Salah satu proyek yang saya kembangkan di hapi (dan bergantung pada banyak dependensi lainnya) tidak menghasilkan kebocoran (setidaknya tidak tertangkap oleh lab ).

@sunknudsen Lebih atau kurang. Ini adalah kombinasi dari paket domain (usang) dan janji sejauh yang saya mengerti. Lihat https://github.com/getsentry/sentry-javascript/blob/master/packages/node/src/handlers.ts#L233

Dalam kasus saya, saya baru saja menghapus sentry middlewares dari server (ekspres) saya untuk memperbaikinya.

Ini bukan masalah di node tetapi di Sentry karena menonaktifkan penangan Sentry memperbaiki masalah;

@MartijnHols Saat ini kami sedang mengerjakan rilis besar yang secara signifikan mengurangi jejak memori SDK kami. Jika Anda suka berpetualang, Anda dapat mencobanya https://github.com/getsentry/sentry-javascript/pull/1919

@HazAT Terima kasih, saya menginstalnya dalam produksi tadi malam (pada pukul 23:10 dalam grafik) dan mengaktifkan kembali penangan dengan hasil di bawah ini. Biasanya ada sedikit lonjakan dalam penggunaan CPU sekitar pukul 23: 00-24: 00 (seperti yang Anda lihat dari hari sebelumnya), tetapi ini sepertinya lebih tinggi. Penggunaan CPU standar juga jauh lebih tajam daripada tanpa penangannya. Tidak yakin apakah ini karena perubahan dalam versi baru atau penangannya sedang diaktifkan. Saya akan mencoba menonaktifkan penangan lagi dalam beberapa jam. Ada sekitar 2,5 kesalahan yang tertangkap per jam.

@MartijnHols Terima kasih telah mencobanya!

Dua hal yang perlu diingat, perbaikan kebocoran memori untuk domain di node baru saja mendarat di node di 11.10 .
Selain itu, kami harus membatalkan penerbitan 5.0.0-beta1 karena salah diberi tag sebagai latest , 5.0.0-rc.1 sekarang menjadi versi next terbaru.
Silakan coba 5.0.0-rc.1 kami membuat sedikit perubahan tentang antrian acara yang seharusnya meningkatkan pemuatan / memori secara signifikan.

Memperbarui ke node 11.12 tampaknya telah menstabilkan penggunaan memori dan CPU. Tampaknya tidak ada perbedaan yang terlihat sekarang dalam penggunaan sumber daya saat membandingkannya dengan menonaktifkan penangan, bahkan mungkin sedikit lebih baik. Tampaknya juga menangkap kesalahan dengan semua info yang saya butuhkan (mungkin ada lebih banyak "remah roti" konsol yang bagus). Tidak yakin apa lagi yang bisa saya periksa untuk 5.0.0. Saya akan memberi tahu Anda jika saya mengalami masalah, tetapi mungkin tidak.

LGTM. Terima kasih!

Saya akan dengan senang hati mencobanya juga. @HazAT tahukah Anda jika perbaikan di 11.10 sudah di-backport ke rilis LTS aktif 10.x ?

@adriaanmeuris Saya pernah membaca bahwa seseorang bertanya apakah itu akan di-backport ke 10.x , tidak yakin apakah mereka akan melakukannya.
ref: https://github.com/nodejs/node/pull/25993#issuecomment -463957701

Saya memecahkan masalah membuat Klien dan Lingkup secara manual di middleware ekspres

Saya membuat file services/sentry yang mengekspor fungsi

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

dan di middleware saya menyimpan klien / ruang lingkup penjaga pada objek permintaan seperti ini

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

Dengan ini tampaknya kebocoran memori sudah diperbaiki

@couds Implementasi ini sangat bagus, ada satu hal yang harus Anda pertimbangkan.

Untuk setiap permintaan Anda akan mendapatkan klien baru dan kami tidak menemukan kesalahan global / remah roti otomatis (atau apa pun yang dilakukan integrasi default).

@HazAT Terima kasih, saya tahu itu, tapi itu harga yang harus dibayar. untuk mengatasi kebocoran memori yang sangat besar itu, tetapi untuk meminimalkan kehilangan ini, saya melakukan beberapa hal.

1. Saya mencoba menangani semua pengecualian yang saya pilih agar tidak bergantung pada peristiwa unCoughException / promise.
2. Untuk remah roti saya menambahkannya secara manual selama saya memiliki akses ke objek req ..
3. Unggah peta sumber ke penjaga dengan @sentry/webpack-plugin
4. Tambahkan Tag / Ekstra pada setiap permintaan yang akan membantu mengidentifikasi masalah

Satu hal lagi, saya lupa menempelkan satu tag lagi yang saya tambahkan yaitu transaksi (untuk mensimulasikan Penangan default)

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

Saya harap ini membantu seseorang, Sentry adalah alat yang sangat hebat dan saya melakukan apa yang saya bisa untuk menghindari menghapusnya dari tumpukan saya.

@HazAT @kamilogorek kita masih melihat pertumbuhan memori yang besar pada [email protected] dan [email protected] - apakah Anda yakin bahwa patch nodejs ini memperbaikinya?

@tpbowden Bisakah Anda memberikan repro ATAU setidaknya mengatakan bagaimana kode Anda terlihat?
Juga, apakah Anda menggunakan plugin lain yang terkait dengan Sentry?

@HazAT Saya sudah mencoba mereproduksi tetapi itu disebabkan oleh server yang cukup kompleks dengan banyak middleware (rendering sisi server React). Dengan middleware Sentry terinstal, kami mencapai pertumbuhan memori yang sangat besar (di bawah beban berat dapat meningkat ~ 10MB / detik). Ketika kami menghapus Sentry.Handlers.requestHandler() middleware dari server kami, memori konstan pada ~ 200MB

Kami tidak menggunakan plugin apa pun, hanya @sentry/node . Dapatkah Anda memikirkan sesuatu yang bisa saya coba untuk membantu mereproduksi ini?

@HazAT Sepertinya terkait dengan bundling Sentry menggunakan webpack di server - hanya terjadi ketika aplikasi dibuat oleh Webpack. Menambahkan @sentry/node ke externals telah memperbaiki masalah memori kita. Tahu mengapa ini terjadi?

Kebocoran masih dapat direproduksi pada Node 11.14.0 menggunakan @ sentry / node 5.1.0

Bagi kami, kebocoran tersebut disebabkan oleh interaksi antara @ sentry / node dan i18next-express-middleware. Aplikasi ekspres kami terlihat mirip dengan https://github.com/i18next/react-i18next/blob/master/example/razzle-ssr/src/server.js.

Jika kita meletakkan .use(Sentry.Handlers.requestHandler()); atas .use(i18nextMiddleware.handle(i18n)) maka kita mendapatkan kebocoran memori. Jika kami menempatkan penjaga di bawahnya, maka kami tidak mendapatkan kebocoran.

Kami memiliki masalah yang sama. Saya mencobanya dengan node 10.15.3 dan 11.14.0 . Ini adalah repositori minimal untuk mereproduksi masalah https://github.com/michalkvasnicak/sentry-memory-leak-reproduction. Jalankan saja yarn test atau yarn test:watch yang akan melaporkan penggunaan heap. Itu selalu meningkat.

yarn test

yarn test:watch

@michalkvasnicak Terima kasih telah meluangkan waktu untuk membuat contoh, saya punya beberapa pertanyaan juga.

Anda tidak benar-benar menguji apa pun tentang SDK

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

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

Anda memerlukan paket tetapi hanya itu.
Saya tidak yakin karena saya belum memiliki pengalaman dengan jest menjalankan tes kebocoran tetapi apa yang bisa bocor dengan hanya membutuhkan paket?
Tidak yakin, mungkin saya melewatkan sesuatu tetapi saya berharap memori bertambah saat memuat paket baru.

Berkenaan dengan apa yang bisa bocor, kami memang membuat beberapa variabel global tetapi kami membutuhkannya untuk melacak status.

@HazAT ya itu aneh tapi cukup untuk membuat tes bocor, jest akan gagal dengan kebocoran terdeteksi. Kami memiliki masalah yang sama di basis kode kami di mana hanya mengomentari impor @sentry/node menyelesaikan masalah dengan kebocoran.

@michalkvasnicak Saya menyelidiki ini dan ini tidak secara langsung disebabkan oleh Sentry.

@sentry/node transport kami memiliki ketergantungan pada https-proxy-agent , yang memiliki ketergantungan pada agent-base yang membutuhkan file patch-core.js _and_ inilah yang membuat kebocoran: shrug:

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

Anda dapat dengan mudah memverifikasi ini dengan menyalin kontennya ke pengujian Anda dan menjalankannya dengan statistik heap:

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

Kami mungkin harus memangkasnya atau menulis solusi.

ada solusi untuk yang satu ini?

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

memperbaiki beberapa kebocoran memori, dapatkah seseorang mengujinya?

Saya memiliki masalah yang sama pada node 11.10, tetapi tampaknya telah diperbaiki pada node 12.3.1

Ada PR terbuka untuk masalah agent-base : https://github.com/TooTallNate/node-agent-base/pull/25

Kita bisa melakukan fork ini dan menimpa dependensi dalam resolusi Yarn atau menemukan cara untuk menggabungkannya.

Mungkin agak offtopic, tetapi juga dapat menyebabkan kebocoran bahwa tidak ada pembersihan domain di Handlers.ts, hanya domain.create?
Artikel sedang atau SO menyarankan harus ada removeListeners dan domain.exit. Tetapi tidak menemukan jawaban pasti untuk itu.

UPDATE: Sekarang saya melihat bahwa penangan menggunakan domain.run yang secara internal memanggil domain.exit. Masih menghapus pendengar / pemancar mungkin membuat perbedaan, tapi jujur ​​tidak tahu.

Saya meningkatkan ke Node 12.4.0 dan saya masih melihat perilaku buruk yang tampaknya terkait dengan Sentry.

Berikut ini beberapa operasi dokter klinik simpul, dilakukan dengan opsi --autocannon selama 90 detik.

• Tanpa inisialisasi penjaga
• Dengan init tetapi tanpa penangan permintaan ekspres
• Dengan penangan dan init (penyiapan produksi kami saat ini)

Tampaknya benar-benar bocor ketika penangan permintaan ada. Jika Anda melihat dasar palung GC saat berlari tanpa penangan, semuanya berada pada level yang sama (65-70mb), di mana lari dengan pawang tampaknya naik sekitar 5mb dengan setiap siklus GC.

@ tstirrat15 perbaikan ini belum dirilis, jadi mungkin itulah sebabnya Anda masih mengalami masalah ini. Bisakah Anda mencoba dari master terbaru jika itu adalah pilihan?

@ tstirrat15 5.4.2 dengan perbaikan yang disertakan telah dirilis, cobalah :)

Berikut proses lain dengan v5.4.2 di tempatnya. Sepertinya masih sedikit bocor ...

GC selalu bekerja dengan benar dan mengembalikan memori ke baseline. Peningkatan penggunaan memori disebabkan oleh remah roti yang dikumpulkan dari acara dan antrean acara, tetapi itu akan berhenti di 100 runut tautan dan tidak akan meningkat lebih jauh. Akan lebih baik jika kita dapat melihat seperti ~ 15-30 menit dump dan melihat apakah memori puncak berhenti di beberapa titik.

Hmm ... kedengarannya bagus. Saya akan membawa PR ini ke produksi dan melihat apakah perilakunya berubah. Terima kasih!

Sepertinya ini terkait dengan bundling Sentry menggunakan webpack di server - hanya terjadi ketika aplikasi dibuat oleh Webpack. Menambahkan @ sentry / node ke eksternal telah memperbaiki masalah memori kita. Tahu mengapa ini terjadi?

@tpbowden Anda benar tentang hal ini, saya memiliki masalah yang sama. Saya menjalankan SDK v5.15.0 dan node v12.3.1, keduanya seharusnya menyertakan semua perbaikan yang diperlukan yang disebutkan di sini.

Saya menggabungkan semua dependensi dalam bundel server saya dengan webpack. Dengan cara ini saya dapat mengirimkan gambar buruh pelabuhan tanpa node_modules, tetapi ada sesuatu yang mengacaukan SDK penjaga dan membocorkan memori saat digabungkan dengan cara ini.

Ini mungkin bug yang dibuat oleh beberapa proses pengoptimalan. Tebakan liar saya adalah mungkin lebih pendek. Beberapa pengoptimalan mungkin mengacaukan penggunaan modul domain, dan penutupan callback yang diteruskan ke scope.addEventProcessor tidak lagi mengumpulkan sampah, jadi setiap permintaan yang dibuat akan membocorkan sejumlah besar memori.

Saya juga menggunakan razzle.js yang agak ketinggalan pada versi webpack / terser, mungkin sudah diperbaiki.

Ini sepertinya bukan bug di pihak penjaga lagi. Saya akan terus menyelidiki ini dan membuka masalah yang sesuai dan terus memperbarui utas ini.

Ini sepertinya bukan bug di pihak penjaga lagi. Saya akan terus menyelidiki ini dan membuka masalah yang sesuai dan terus memperbarui utas ini.

Terus kabari kami, terima kasih!

@kamilogorek Bisakah Anda menunjukkan di mana dalam kode pemroses kejadian callback yang ditambahkan ke larik _eventProcessors dalam contoh Scope dihapus? Saya tidak dapat menemukannya. Tampaknya semua permintaan menambahkan callback prosesor peristiwa ke array ini, dan permintaan tersebut tidak pernah dihapus. Jika saya ingin tahu bagaimana mereka seharusnya dihapus, itu mungkin membantu saya memahami bug dengan lebih baik.

Atau mungkin seluruh cakupan yang seharusnya unik dan sampah dikumpulkan untuk setiap permintaan? Tampaknya setiap permintaan mendapatkan instance lingkup yang sama 🤔

Atau mungkin seluruh cakupan yang seharusnya unik dan sampah dikumpulkan untuk setiap permintaan?

Itu betul. Namun, scope harus digandakan untuk setiap domain 🤔

Lihat tumpukan panggilan ini:

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! Saya rasa saya menemukan sesuatu.

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

Tetapi ketika saya masuk ke kode dynamicRequire:
https://github.com/getsentry/sentry-javascript/blob/fd26d9fa273002502706b03fc1a9a46864cd8440/packages/utils/src/misc.ts#L28-L31

require tidak ditentukan pada mod 🤯

Jadi itu memasuki blok catch dari fungsi getHubFromActiveDomain dan sebagai gantinya menggunakan getHubFromCarrier() !

Karena dalam pengaturan saya _everyting_ dibundel oleh webpack, mungkin ada beberapa asumsi yang dibuat pada objek mod yang dirusak oleh webpack. Apakah Anda punya ide tentang bagaimana ini bisa diperbaiki? 🤔

Rekap

Kami menggunakan dynamicRequire:

mod.require tidak ditentukan:

Seperti apa objek mod itu:

Kami akhirnya menggunakan getHubFromCarrier:

Saya secara manual menambal modul Hub langsung di folder node_modules saya. Saya menghapus baris menggunakan dynamicRequire dan baru saja menambahkan import domain from 'domain'; di bagian atas file dan ... sekarang berfungsi dengan sempurna! Tidak ada lagi kebocoran! 🎉

Mungkin peretasan dynamicRequire diperlukan sebelumnya, tetapi tidak lagi diperlukan dengan versi webpack yang lebih baru? 🤔

Saya juga mencoba mengganti:

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

dengan:

const domain = require('domain');

dan itu juga berfungsi dengan baik. Saya tidak tahu solusi mana yang Anda pilih.

Apakah Anda ingin saya membuka PR dengan perbaikan ini?