Sentry-javascript: Kembalikan janji dari metode penangkapan API utama*

Terima kasih telah menyoroti ini, untuk memperjelas bahwa ini tidak sepenuhnya sinkron, "transportasi" berjalan di latar belakang. Jadi sebenarnya tidak ada jaminan event tersebut mengenai Sentry.

eventId dihasilkan di SDK secara lokal dan akan digunakan untuk menyerap acara di server.

Kami akan memperbarui dokumen kami untuk memperjelas hal ini.

Oke, jadi sekedar memperjelas, memang perlu mengimplementasikan apa yang digariskan di sini: https://docs.sentry.io/error-reporting/configuration/draining/?platform=node

Apakah ini benar, @HazAT?

@rhyek Benar, jika ingin memastikan semuanya terkirim, Anda bisa menunggu flush untuk memastikan semuanya terkirim.

Bukankah lebih baik mengekspos janji dari metode capture* ? API akan lebih jelas karena mengembalikan janji memberi tahu pengguna bahwa mereka harus await untuk memastikan acara dikirim atau hanya api-dan-lupa berharap itu dikirim. Baik close dan flush adalah metode utilitas ambigu yang mencoba membuat sesuatu yang sinkron dianggap asinkron. Plus, kedua metode ini benar-benar rusak: sebenarnya, ada beberapa kebiasaan (saya akan mengatakan bahwa itu adalah bug tetapi mungkin ini tergantung pada POV orang yang melihatnya):

• tujuan dari timeout diteruskan ke flush adalah null karena tidak dipatuhi oleh transport dengan mengganggu pengiriman permintaan. Itu hanya menyelesaikan janji yang dikembalikan ke false ketika penghitung waktu berakhir. Saya masih bertanya pada diri sendiri tentang kegunaan kode dan perilaku seperti itu ...
• metode flush mengembalikan janji baru setiap kali dipanggil yang diselesaikan segera setelah timeout tercapai. Ada dua masalah: seluruh kode yang dieksekusi oleh setInterval sangat lambat, setidaknya dalam pengujian saya di konsol browser, dan janji diselesaikan beberapa detik setelah batas waktu berakhir. Masalah kedua dan yang lebih penting adalah bahwa kode fungsi _isClientProcessing menghapus batas waktu setiap kali dipanggil, jadi jika seseorang melakukan sesuatu seperti Promise.all([fush(), flush()]) (Saya tidak tahu mengapa dia harus melakukannya itu, tetapi karena API mengembalikan janji baru setiap kali dia mungkin tergoda untuk melakukannya) maka janji tersebut tidak akan pernah diselesaikan.

Benar, jika ingin memastikan semuanya terkirim, Anda bisa menunggu flush untuk memastikan semuanya terkirim.

Salah, lihat poin saya di atas untuk memahami mengapa bahkan menunggu flush Anda tidak dapat memastikan bahwa semuanya terkirim. Saya akan mengatakan bahwa desain API seperti itu benar-benar rusak dan saya tidak dapat benar-benar mengerti mengapa tidak menyerahkan kepada pengguna pilihan untuk menunggu janji yang mewakili pengiriman acara alih-alih mencoba membangun API shutdown yang bahkan tidak dapat bekerja untuk semua bahasa tempat API Terpadu seharusnya bekerja

Saya pikir memiliki akses ke janji yang diselesaikan ketika acara akhirnya
dikirim selain metode lain yang dijelaskan di utas ini membuat
banyak akal.

Pada Sabtu, 11 Mei 2019, 12:29 Stefano Arlandini [email protected]
menulis:

Bukankah lebih baik untuk mengungkapkan janji dari penangkapan*
metode? API akan lebih jelas karena mengembalikan janji, beri tahu pengguna bahwa
mereka harus menunggu untuk memastikan acara dikirim atau hanya
api-dan-lupa berharap itu akan dikirim. Baik close dan flush adalah metode
utilitas ambigu yang mencoba membuat sesuatu yang sinkron menjadi
berpikir untuk menjadi asinkron. Plus, kedua metode ini benar-benar rusak: di
sebenarnya, ada beberapa kebiasaan (saya akan mengatakan bahwa itu adalah bug tapi
mungkin ini tergantung pada POV orang yang melihatnya):

• tujuan dari batas waktu yang dilewatkan ke flush adalah nol karena bukan
  dihormati oleh transportasi dengan mengganggu pengiriman permintaan. Dia
  hanya menyelesaikan janji yang dikembalikan menjadi salah ketika penghitung waktu berakhir.
  Saya masih bertanya pada diri sendiri tentang kegunaan kode dan perilaku seperti itu ...
• metode flush mengembalikan janji baru setiap kali disebut itu
  diselesaikan segera setelah batas waktu tercapai. Ada dua masalah:
  seluruh kode yang dieksekusi oleh setInterval sangat lambat, setidaknya dalam
  pengujian saya di konsol browser, dan janji itu menyelesaikan banyak hal
  detik setelah batas waktu berakhir. Masalah kedua dan yang lebih penting adalah
  bahwa kode fungsi _isClientProcessing menghapus batas waktu
  setiap kali dipanggil, jadi jika seseorang melakukan sesuatu seperti Promise.all([fush(),
  flush()]) (Saya tidak tahu mengapa dia harus melakukannya, tetapi karena API kembali
  janji baru setiap kali dia mungkin tergoda untuk melakukannya) maka janji tersebut akan
  tidak pernah bisa diselesaikan.

Benar, jika Anda ingin memastikan semuanya terkirim, Anda bisa menunggu flush
untuk memastikan semuanya terkirim.

Salah, lihat poin saya di atas untuk memahami mengapa bahkan menunggu flush Anda
tidak dapat memastikan bahwa semuanya terkirim. Saya akan mengatakan bahwa desain API seperti itu adalah
benar-benar rusak dan saya benar-benar tidak mengerti mengapa tidak menyerahkannya kepada pengguna
pilihan menunggu janji yang mewakili pengiriman suatu peristiwa
alih-alih mencoba membangun API shutdown yang bahkan tidak bisa bekerja untuk semua
bahasa tempat API Terpadu seharusnya bekerja

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/getsentry/sentry-javascript/issues/2049#issuecomment-491533914 ,
atau matikan utasnya
https://github.com/notifications/unsubscribe-auth/AAFLTSVSICZ7Y26UHCSMKWLPU4GATANCNFSM4HKUJ5ZQ
.

Saya juga akan mengatakan bahwa saya tidak mengharapkan metode mengembalikan hasil untuk menjalankan sesuatu di latar belakang karena ini adalah sumber kebingungan bagi pengguna (dan pertanyaan utama dari masalah ini tentu saja). Sebaliknya, jika janji dikembalikan maka jelas itu hanya pengganti untuk sesuatu yang akan datang di masa depan dan yang belum siap. Pilihan untuk menunggu atau hanya menembak-dan-melupakannya terserah pengguna jelas. Juga, karena ID acara dibuat secara lokal (saya tidak melihat alasan untuk melakukannya, btw), Anda dapat menggunakan sesuatu (karena segera dikembalikan) yang tidak valid karena untuk beberapa alasan transportasi gagal mengirim acara dan Anda tidak 'bahkan tidak tahu tentang itu

Telah mengalami sedikit masalah dengan Sentry sejak kami meningkatkan ke @sentry/node , kami mungkin akan kembali ke raven-node sampai ada solusi yang lebih baik.

Harus menguras antrian pada batas waktu sewenang-wenang di akhir setiap eksekusi tanpa server pasti terasa lebih seperti peretasan, dan bukan solusi. 🤔.

Bagi mereka yang mencari lebih banyak contoh tentang apa yang mungkin berhasil — saya menemukan beberapa solusi dalam #1449 membantu seputar pembilasan dan semacamnya, mereka juga membahas banyak masalah ini.

(Mereka fokus pada lambda dan tanpa server tetapi konsep yang sama kemungkinan akan bekerja di lingkungan lain juga karena ini adalah pendekatan pembilasan).

Pasti ingin ada cara yang lebih baik di beberapa titik yang tidak melibatkan pembilasan setiap saat.

Sepenuhnya setuju dengan apa yang dikatakan di utas ini, IMO benar-benar membingungkan memiliki metode sinkron yang menyembunyikan asinkron di latar belakang.
Mungkin tim penjaga memiliki alasan yang sangat bagus untuk melakukannya dengan cara ini, bagaimanapun juga pembaruan pada dokumentasi akan sangat dihargai.

@cibergarri Saya pikir alasannya adalah agar eventId dapat segera dikembalikan tanpa memblokir kode userland pada panggilan jaringan yang berpotensi lambat ke apis penjaga. Saya setuju bahwa itu membingungkan untuk mengembalikan nilai dari api asinkron dan berpotensi menyebabkan hilangnya kesalahan secara diam-diam dalam konteks eksekusi tanpa server yang tidak bertahan cukup lama untuk panggilan lapisan transport asinkron. Salah satu solusinya adalah dengan membagi fungsi menjadi dua sehingga pengguna perlu ikut serta dalam perilaku asinkron, mis

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

Atau sebagai parameter, mis

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

ID peristiwa selalu dibuat di klien, jadi async atau sync API tidak masalah dan akibatnya itu bukan indikator yang baik apakah suatu peristiwa telah dikirim atau tidak nyata (masalah lain imo). Saya juga sudah lama mengusulkan untuk PHP SDK solusi serupa yang melibatkan metode sinkron dan asinkron untuk setiap metode capture* tetapi ditolak. Saya tidak sepenuhnya memahami alasan sebenarnya Unified API ingin menyembunyikan asinkronisitas dan pengembang tidak ingin mengungkapkan janji, tetapi bagi saya tampaknya mereka tidak begitu terbuka untuk mengubah ini.

Sayangnya, masalah ini membuat saya beralih dari Sentry karena membuat kesalahan pelacakan di lingkungan tanpa server terlalu rawan kesalahan. (Oh, ironi.)

Metode capture*Async akan sangat membantu 👍

Bisakah kita mendapatkan pembaruan tentang ini?

@marcospgp apa yang ingin Anda ketahui dengan tepat? Segala sesuatu yang Daniel tulis masih berlaku sampai hari ini.

Saya pikir dokumentasi itu terpisah, cukup jelas dari reaksi pada komentar dan komentar itu sendiri bahwa pengguna ingin memiliki akses ke janji, dan tidak ada alasan bagus untuk tidak mengizinkan ini

Sayangnya, itu tidak akan terjadi sebelum rilis v6, karena ini melanggar perubahan pada API utama kami dan akan membutuhkan banyak perubahan. Saya akan menambahkan ini ke peta jalan untuk menjaga ini tetap dicatat.