Sentry-javascript: नोड सुझाव: `unhandledRejection` . में लॉग त्रुटियाँ

अच्छा लगता है, हालांकि, मुझे यकीन नहीं है कि यह हमारे debug: true ध्वज के पीछे होना चाहिए।
अंत में, आप जानबूझकर त्रुटि हैंडलर संलग्न कर रहे हैं, जो त्रुटि स्ट्रीम को संतरी पर पुनर्निर्देशित करता है।

मुझे भी यकीन नहीं है।

संतरी को सक्षम करने से अनकैप्ड अपवादों के लिए लॉगिंग को अक्षम करने का प्रभाव नहीं पड़ता है, इसलिए हो सकता है कि अनहेल्ड वादों को अस्वीकार करने के लिए भी यही सच हो। (हालांकि व्यवहार में यह अंतर संतरी की तुलना में नोड में अधिक असंगति है।)

जब मैं सेंट्री को सक्षम करता हूं तो मैं समझता हूं कि यह मेरी त्रुटियों की रिपोर्ट कर रहा है, लेकिन मैं कंसोल लॉगिंग को एक अलग चीज के रूप में सोचता हूं, खासकर देव में। मैं

हम डिफ़ॉल्ट लॉगिंग व्यवहार को संशोधित नहीं करते हैं, और बिना किसी अपवाद के यह नोड ही है जो लॉग कॉल को ट्रिगर कर रहा है।

मुझे लगता है कि यहां सबसे अच्छा समाधान यह होगा कि आप इसके बारे में डॉक्स में नोट कर लें और छोड़ दें

process.on('unhandledRejection', (reason, p) => {
  console.log('Unhandled Rejection at:', p, 'reason:', reason);
});

यदि कोई व्यक्ति चेतावनी को फिर से सक्षम करना चाहता है तो उसे स्निपेट करें।

डॉक्स पर्याप्त होंगे। कम से कम तब संतरी कुछ खास नहीं कर रहा है। यह वास्तव में नोड है कि यहाँ समस्या है।

हो गया https://github.com/getsentry/sentry-docs/pull/785

या न आया हुआ अपवाद यह स्वयं नोड है जो लॉग कॉल को ट्रिगर कर रहा है।

दूसरे विचारों पर, मुझे यकीन नहीं है कि यह सच है।

संतरी एक uncaughtException हैंडलर पंजीकृत करता है जो डिफ़ॉल्ट नोड व्यवहार (लॉग + निकास) को अक्षम करता है।

हैंडलर ( defaultOnFatalError ) अपना लॉग कॉल ट्रिगर करता है: https://github.com/getsentry/sentry-javascript/blob/4.6.3/packages/node/src/handlers.ts#L282।

अगर हम अनकैप्ड अपवादों के लिए लॉगिंग को "बहाल" कर रहे हैं, तो मेरा मानना ​​है कि हमें अनहेल्ड वादों को अस्वीकार करने के लिए भी यही काम करना चाहिए।

क्या हम इसे फिर से खोल सकते हैं? मेरी पिछली टिप्पणी के अनुसार, अब मेरा मानना ​​है कि संतरी को अनहेल्ड वादों को अस्वीकार करने के लिए लॉगिंग को पुनर्स्थापित करना चाहिए, जैसे कि यह अनकैप्ड अपवादों के लिए करता है।

मुझे यह समस्या इसलिए मिली क्योंकि मैं संतरी का उपयोग करना शुरू कर रहा था और सोचता था कि क्या मैंने अपने कोड में कोई गलती की है क्योंकि मेरे लॉग में केवल uncaughtException था न कि unhandledRejection । इन दोनों मामलों को एक ही तरह से संभालने के लिए यह बहुत मायने रखता है।

तो मैं कहूंगा कि या तो दोनों को लॉग इन करें या न ही लॉग इन करें।

मुझे नोड के कोर से कोड कॉपी करने की तुलना में इसे संभालने का एक बेहतर तरीका मिला।

λ: node --unhandled-rejections=warn app.js

मुख्य दस्तावेज़ पृष्ठ https://github.com/getsentry/sentry-docs/pull/1099 पर शामिल करके इसे भी स्पष्ट किया

मुझे अभी भी यह अजीब लगता है कि uncaughtException और unhandledRejection को अलग तरह से संभाला जाता है। संतरी uncaughtException लिए लॉगिंग को पुनर्स्थापित करता है—यह unhandledRejection लिए ऐसा क्यों नहीं करता है? उपयोगकर्ताओं को उस नोड ध्वज का उपयोग करने के लिए याद नहीं रखना चाहिए। मैं

यह अनचाहे अस्वीकृति के लिए ऐसा क्यों नहीं करता है?

क्योंकि एक महत्वपूर्ण है ( unhandledException प्रक्रिया को मारता है), और एक सूचनात्मक है (इस प्रकार यह एक चेतावनी है, त्रुटि नहीं)।

यदि हम ऑर्डर को उलट देते हैं और डिफ़ॉल्ट रूप से चेतावनी देते हैं, तो हम --unhandled-rejections को none सेट किए जाने के बावजूद, उन्हें उत्सर्जित करके CLI व्यवहार को तोड़ देंगे। आधिकारिक नोड दस्तावेज़ीकरण के अनुसार अभी सब कुछ अपेक्षित रूप से काम करता है। यह बदलाव इसे गैर-मानक बना देगा।

एक बार जब नोड unhandledRejection बनाने का निर्णय लेता है तो एक प्रक्रिया भी समाप्त हो जाती है (जिसे वे अब 4 संस्करणों के लिए कहते हैं: पी), हम परिवर्तन को आधिकारिक विनिर्देश के साथ-साथ ऑनलाइन भी करेंगे।

यदि हम आदेश को उलट देते हैं और डिफ़ॉल्ट रूप से चेतावनी देते हैं, तो हम CLI व्यवहार को तोड़ देंगे

@kamilogorek , लेकिन node साथ चलने पर यह unhandledRejection से console लॉग इन करता है। तो मुझे नहीं पता कि आधिकारिक नोड दस्तावेज क्या कहता है, लेकिन कम से कम यही वह व्यवहार है जिसे मैं नोटिस करता हूं।

@freeall केवल अगर आप unhandledRejection हैंडलर संलग्न नहीं करते हैं। यदि आप एसडीके के बिना भी नीचे दिए गए कोड को चलाते हैं, तो यह अभी भी लॉग नहीं करेगा, इस प्रकार आपको पता होना चाहिए कि आप कौन सा कोड चला रहे हैं।

process.on('unhandledRejection', () => `¯\_(ツ)_/¯`);

और हम यहां बहुत स्पष्ट रूप से बताते हैं कि हम ऐसा करते हैं: https://docs.sentry.io/platforms/node/default-integrations/

सिस्टम एकीकरण डिफ़ॉल्ट रूप से सक्षम एकीकरण हैं जो मानक पुस्तकालय या स्वयं दुभाषिया में संयोजित होते हैं। वे प्रलेखित हैं ताकि आप देख सकें कि वे क्या करते हैं और यदि वे समस्याएँ पैदा करते हैं तो उन्हें अक्षम किया जा सकता है।
ऑनअनहैंडल रिजेक्शन
यह एकीकरण वैश्विक अनहेल्ड रिजेक्शन हैंडलर्स को जोड़ता है।

मैं नोड के व्यवहार को बदलना नहीं चाहता, बस। और व्यवहार है: "यदि कोई श्रोता है, तो उत्सर्जन न करें। यदि आप अभी भी चेतावनी चाहते हैं, तो ध्वज का उपयोग करें।" - और ठीक यही हम करते हैं।

@kamilogorek मैं समझता हूं कि आप कहां से आ रहे हैं। लेकिन मुझे लगता है कि संतरी के उपयोगकर्ता संतरी से अपेक्षा करेंगे कि वह अपने कार्यक्रम के व्यवहार में बदलाव न करे।

अगर मेरे पास संतरी के बिना unhandledRejection मैं इसे अपने कंसोल में देखता हूं।
अगर मेरे पास संतरी के साथ unhandledRejection तो मैं इसे अपने कंसोल में नहीं देखता हूं।

मुझे व्यक्तिगत रूप से यह पसंद नहीं है कि संतरी व्यवहार को बदल दे।

लेकिन इस तरह Node.js डिज़ाइन किया गया है _(ツ)_/¯
यदि आप हैंडलर जोड़ते हैं, तो चेतावनी समाप्त हो जाती है। हमारा एसडीके हैंडलर जोड़ता है, क्योंकि अनहेल्ड त्रुटियों को पकड़ने का यही एकमात्र तरीका है, जो एसडीके का मुख्य उद्देश्य है।

आप निश्चित रूप से सही हैं कि नोड कैसे डिज़ाइन किया गया है। जब आप एक हैंडलर संलग्न करते हैं तो चेतावनी समाप्त हो जाती है।
लोग क्या पूछ रहे हैं कि आप नोड के डिफ़ॉल्ट व्यवहार की नकल करते हैं और इसे कंसोल पर लॉग करते हैं। बदला हुआ व्यवहार वह नहीं है जिसकी आप संतरी जैसे उपकरण से अपेक्षा करते हैं

वैसे भी, ऐसा लगता है कि आप इस व्यवहार पर सेट हैं इसलिए चर्चा जारी रखने का कोई मतलब नहीं है। लेकिन उत्तर देने के लिए समय निकालने के लिए धन्यवाद :)

@freeall भी धन्यवाद, दोनों पक्षों को देखना हमेशा अच्छा होता है :)

बस स्पष्ट करने के लिए: संतरी को सक्षम करते समय, unhandledException (निकास + लॉग) का व्यवहार संरक्षित है, लेकिन unhandledRejection (लॉग) का व्यवहार नहीं है:

|हैंडलर|लॉग|निकास|
|-|-|-|
| unhandledException डिफ़ॉल्ट|हाँ|हाँ|
| unhandledException संतरी|हाँ|हाँ|
| unhandledRejection डिफ़ॉल्ट|हाँ|नहीं|
| unhandledRejection संतरी|नहीं|नहीं|

आधिकारिक नोड दस्तावेज़ीकरण के अनुसार अभी सब कुछ अपेक्षित रूप से काम करता है।

"उम्मीद के मुताबिक" यहां माना जा रहा है कि उपयोगकर्ता समझता है कि संतरी unhandledRejection लिए श्रोता को पंजीकृत कर रहा है। यह एक कार्यान्वयन विवरण है जिसके बारे में उपयोगकर्ताओं को चिंता करने की आवश्यकता नहीं है।

हालांकि मैं आपकी बात देखता हूं। संतरी को भी --unhandled-rejections सम्मान करना चाहिए, जो कि अगर ध्वज को none सेट किया गया होता और संतरी लॉग करना जारी रखता तो ऐसा नहीं होता।

@freeall टिप्पणी इसे बहुत अच्छी तरह से बताती है:

मुझे लगता है कि संतरी के उपयोगकर्ता संतरी से अपेक्षा करेंगे कि वह अपने कार्यक्रम के व्यवहार में बदलाव न करे।

ध्यान में न आया वादा अस्वीकृति कोई "द्वितीय श्रेणी त्रुटि" नहीं है। वे सामान्य त्रुटियों की तरह ही ऐप्स को तोड़ने का कारण बन सकते हैं और कर सकते हैं।

ऐसा लगता है कि कई उपयोगकर्ता इस समस्या (मेरे सहित) में चले गए हैं, और भविष्य में और भी इसमें भाग लेंगे।

तो संक्षेप में: संतरी कंसोल से त्रुटियों को शांत करता है। और मुझे लगता है कि यह स्पष्ट है कि यह कैसे भ्रमित करने वाला है, और शायद अधिकांश संतरी उपयोगकर्ताओं द्वारा इसका इरादा नहीं है। वे कंसोल से खामोश त्रुटियों के कुछ सबसेट के लिए संतरी स्थापित नहीं करते हैं।

तो तर्क ( @kamilogorek द्वारा)

इस प्रकार Node.js डिज़ाइन किया गया है

मेरे लिए थोड़ा गूढ़ है। यह कैसे तय करता है कि संतरी को किस तरह से व्यवहार करना चाहिए?

क्या हमें उम्मीद करनी चाहिए कि उपयोगकर्ता इसके बारे में जानें:

ए) संतरी आंतरिक कामकाज (इवेंट हैंडलर पंजीकृत करता है)

बी) नोड आंतरिक कामकाज (हैंडलर जोड़ने से चेतावनियां गायब हो जाती हैं)

और अगर वे नहीं करते हैं, तो उन्हें करना चाहिए?

बेशक आप सही कह रहे हैं "ठीक है, उपयोगकर्ता को पता होना चाहिए कि कोड हुड के नीचे क्या करता है", लेकिन वास्तविकता अलग दिखती है। और आपके पास यहां संतरी के उपयोग में आसानी को बढ़ाने का अवसर है, या नहीं।

यह कहना ठीक है कि "हमें इस विशेष मुद्दे की परवाह नहीं है", लेकिन इसे "यह एक बग नहीं है, यह एक विशेषता है" में चित्रित करना एक तरह से कपटपूर्ण लगता है।

TLDR: IMOH यदि आप उपयोग में आसानी बढ़ाना चाहते हैं, और नौसिखिया उपयोगकर्ताओं के लिए समस्याओं को कम करना चाहते हैं, तो इसे ठीक किया जाना चाहिए।

@OliverJAsh , @freeall
इस समस्या के लिए आपने किन समाधानों का उपयोग किया?

@schhumannd मैंने एक स्निपेट जोड़ा है कि मैं इसे कैसे लोड करता हूं। और मैं आपसे सहमत हूं कि "यह एक बग नहीं है, यह एक विशेषता है" उत्तर पूरा नहीं होता है। मुझे डर है कि कई प्रोग्रामर अपने प्रोग्राम में कुछ बग नहीं पकड़ेंगे क्योंकि संतरी उन्हें खा जाते हैं। मेरे लिए, संतरी जैसे टूल की पहली प्राथमिकता बग को पकड़ना होना चाहिए, न कि उन्हें बनाना।

...
if (isUsingSentry) {
  // Log to console because Sentry overwrites standard behavior. https://github.com/getsentry/sentry-javascript/issues/1909.
  // Note that it doesn't overwrite for uncaughtException.
  process.on('unhandledRejection', console.error)
}
...

जैसा कि मैं प्रतिक्रिया देशी में संतरी का उपयोग कर रहा हूं, ऐसा लगता है कि मुझे इस मुद्दे को ठीक करने के लिए कुछ हैकी चीजें करने की आवश्यकता होगी। क्या कोई रिएक्ट नेटिव का उपयोग कर रहा है और इस समस्या को अलग तरीके से हल कर रहा है?

@OliverJAsh , @kamilogorek
क्या हम कृपया इसे फिर से खोलकर ठीक कर सकते हैं?

संतरी को बिल्कुल गड़बड़ नहीं करनी चाहिए कि कंसोल में त्रुटियों को कैसे लॉग किया जाता है - और यह केवल नोड के साथ एक समस्या नहीं है, क्योंकि ब्राउज़र में कंसोल लॉगिंग को भी दबा दिया जाता है।

चीजों को डीबग करने का प्रयास करते समय यह बहुत कष्टप्रद होता है, और चूंकि आपने जावास्क्रिप्ट के लिए दस्तावेज़ों में इसका उल्लेख करने की जहमत नहीं उठाई, मुझे वास्तव में लगा कि स्टेजिंग बिल्ड का परीक्षण करते समय जब मैंने कंसोल में देखा तो मुझे कोई त्रुटि नहीं थी, और इसलिए इसका एहसास नहीं हुआ त्रुटियां थीं, जब तक कि इसे उत्पादन में तैनात नहीं किया गया था। त्रुटि रिपोर्टिंग सेवा के लिए यह वास्तव में एक अजीब उपयोगकर्ता अनुभव है, और यदि आप खुश ग्राहक चाहते हैं तो आपको इसे ठीक करने की आवश्यकता है।

और जैसा कि पहले कहा गया है, वादा अस्वीकृति दूसरी श्रेणी की त्रुटियां नहीं हैं - वे किसी भी अन्य अनियंत्रित त्रुटि की तरह ही घातक हो सकती हैं, और उन्हें किसी भी तरह से दबाया नहीं जाना चाहिए।

तो, कुछ डिबगिंग से पता चलता है कि कंसोल लॉगिंग को दबा दिया गया है:

संतरी window.onunhandledrejection को एक फ़ंक्शन असाइन करता है, और जैसा कि हम यहां देखते हैं, वह फ़ंक्शन false लौटाता है, जिससे कंसोल लॉगिंग को स्पष्ट रूप से दबा दिया जाता है। तो हाँ, संतरी _does_ डिफ़ॉल्ट व्यवहार बदलें - यह अच्छा नहीं है।

सौभाग्य से, यह किसी भी मौजूदा फ़ंक्शन का संदर्भ संग्रहीत करता है, और कॉल करता है कि यदि यह मौजूद है।
तो, कंसोल लॉगिंग को फिर से सक्षम करने के लिए हैकी वर्कअराउंड, सेंट्री को इनिशियलाइज़ करने से पहले इस लाइन को जोड़ना है:

window.onunhandledrejection = () => true;

अब, कृपया इसे ठीक करें, ताकि हम ऐसे व्यर्थ हैक्स के बिना डिफ़ॉल्ट व्यवहार कर सकें

@schhumannd कृपया इस मुद्दे को फिर से खोलें

@ थॉमस-डार्लिंग मैं ब्राउज़र परिवर्तन से सहमत हूं, इसे वादों के लिए भी true वापस करना चाहिए और मैं इसे बदल सकता हूं।

हालाँकि, नोड के लिए, मैं अभी भी एक कारण से आश्वस्त नहीं हूँ। यह कोड को वर्तमान नोड कार्यान्वयन से जोड़ता है। अगर हम झंडों पर भरोसा करने के बजाय आंतरिक की नकल करेंगे, और वादा अस्वीकृति व्यवहार v14 में बदल जाएगा, तो हमें यह पता लगाना होगा कि हम किस नोड में हैं और उसके अनुसार कार्य करते हैं।
इससे कोई फर्क नहीं पड़ता कि हम श्रोता से क्या लौटाते हैं, क्योंकि आंतरिक रूप से नोड केवल श्रोताओं की सरणी के लिए जाँच करता है और केवल तभी चेतावनी देता है जब कोई श्रोता न हो, और इस पहचान को संशोधित नहीं किया जा सकता है - https://github.com/nodejs /नोड/ ब्लॉब/ lib/ आंतरिक/ js #

ब्राउज़र परिवर्तन के संबंध में अच्छा लगता है: +1:

नोड के लिए, यदि आप संतरी में लॉगिंग को ठीक नहीं करते हैं, तो आप मूल रूप से अपने सभी उपयोगकर्ताओं को इसे स्वयं करने के लिए मजबूर करते हैं - अतिरिक्त जोखिम के साथ कि कुछ इसे गलत करेंगे, और कुछ को यह भी एहसास नहीं होगा कि उन्हें इसकी आवश्यकता है, जब तक कि वे एक प्रोडक्शन बग ने काट लिया, जैसे मैंने किया। यह एक अच्छा डेवलपर अनुभव नहीं है ...

@ थॉमस-डार्लिंग आप इसे कैसे ठीक करना चाहेंगे? उसी कोड को पुन: उत्पन्न करें जो नोड के कोड के अंदर है?

हमारे डॉक्स के शीर्ष पर एक बहुत ही दृश्यमान नोट है कि डिफ़ॉल्ट कंसोल लॉगिंग प्राप्त करने के लिए क्या करना है - https://docs.sentry.io/platforms/node/

मैं आपकी बात देखता हूं - नोड व्यवहार को दोहराने के लिए एक संभावित रखरखाव समस्या होगी, और यह मदद करता है कि यह नोड के लिए, एक साधारण कमांड लाइन ध्वज के साथ हल किया जा सकता है।

लेकिन अगर आप नोड व्यवहार को दोहराना नहीं चाहते हैं, तो कम से कम कंसोल पर एक चेतावनी लॉग करें जब वह ध्वज निर्दिष्ट नहीं होता है, तो उपयोगकर्ता जानते हैं कि त्रुटियों को दबाया जा रहा है, और इससे कैसे बचा जाए।

यह नोड के अगले संस्करण में और भी महत्वपूर्ण हो जाता है, जहां अप्रतिबंधित अस्वीकृति, डिफ़ॉल्ट रूप से, प्रक्रिया को क्रैश कर देगी - जो, जैसा कि मैं इसे समझता हूं, तब नहीं होगा जब संतरी अपने हैंडलर को जोड़ता है।
उपयोगकर्ता जो नोड में उस नए डिफ़ॉल्ट व्यवहार पर भरोसा करते हैं, संभावित रूप से एक बुरा आश्चर्य हो सकता है, अगर वे बाद में संतरी स्थापित करते हैं और उनकी प्रक्रिया अचानक जारी रहती है, एक घातक त्रुटि होने के बावजूद।
यह उस तरह की चीज है जिससे डेटा हानि या अन्य आपदाएं हो सकती हैं।

जैसा कि मैंने इसे देखा है कुछ विकल्प हैं:

1. इसे करने के Node.js के तरीके को दोहराएं
2. जब कोई हैंडल न किया गया अस्वीकृति हो तो बस console.error लिखें
3. त्रुटि को दबाएं ताकि डेवलपर इसे कभी न देख सके

मुझे लगता है कि विकल्प 1 या 2 दोनों ठीक लगते हैं। आपका ग्राहक त्रुटि देखता है और उसे ठीक कर सकता है।
आपको जो बिल्कुल नहीं करना चाहिए वह विकल्प 3 है, जहां आपके ग्राहक को त्रुटियां नहीं दिखाई देती हैं और संतरी उत्पादन में त्रुटियों का कारण बनता है (ओह, लेकिन एक त्रुटि रिपोर्टिंग टूल के लिए विडंबना)। यह वर्तमान व्यवहार है और इसे वास्तव में बंद कर देना चाहिए! संतरी को त्रुटियों को पकड़ने में मेरी मदद करनी चाहिए, इसे और खराब नहीं करना चाहिए।

यहां तक ​​कि अगर आप विकल्प 2 चुनते हैं, तो कम से कम डेवलपर्स को अस्वीकृति दिखाई देगी और वे देखेंगे कि वे एक अलग व्यवहार (एक दुर्घटना की तरह) चाहते थे, और इसे लागू कर सकते हैं। लेकिन यह जाने बिना कि एक अस्वीकृति भी थी, वे इसके बारे में ज्यादा कुछ नहीं कर सकते।

यह काम करना चाहिए। https://github.com/getsentry/sentry-javascript/pull/2312
मैंने आपके स्वयं के कॉलबैक को जोड़ने का कोई तरीका नहीं जोड़ा, क्योंकि नीचे दिए गए कोड का ठीक वैसा ही प्रभाव होगा:

```जेएस
संतरी.इनिट({
एकीकरण: [
नई संतरी। एकीकरण
मोड: 'कोई नहीं'
})
]
});

process.on('unhandledRejection', (कारण) => {
// आपका कॉलबैक
})

मेरे लिए जिसके परिणामस्वरूप TypeError: undefined is not a constructor । हो सकता है, क्योंकि मैं अब @sentry/react-native पैकेज का उपयोग कर रहा हूं। बीटीडब्ल्यू क्या उस पैकेज में एक ही समस्या है?

@schhumannd @sentry/react-native @sentry/node उपयोग नहीं करता है, इसलिए इसमें यह एकीकरण नहीं है। उसके लिए, हमारे द्वारा संतरी/ब्राउज़र जारी करने के बाद आपको बस एक संस्करण को अपडेट करना होगा और यह ठीक काम करेगा (क्योंकि हैंडलर से true वापस करने के लिए परिवर्तन डिफ़ॉल्ट और गैर-कॉन्फ़िगर करने योग्य है)।

@kamilogorek मुझे अच्छा लग रहा है

इसे करने के लिए आपका धन्यवाद! क्या इसे जारी होने के बाद आप यहां पिंग कर पाएंगे?

@OliverJAsh पिंग :)

बस यह जांचने के लिए कि मैं सही ढंग से समझता हूं: यदि मैं नोड के --unhandled-rejections=strict ध्वज का उपयोग करता हूं, तो नोड अपवाद के रूप में अनचाहे अस्वीकृति को उठाएगा, और फिर संतरी उस अपवाद को रोक देगा और इसकी रिपोर्ट करेगा? मुझे लगता है कि मैं यही देख रहा हूं।

मैं पूछता हूं क्योंकि जब मैंने --unhandled-rejections=strict सक्षम करने का प्रयास किया, तो ऐसा लगा कि OnUnhandledRejections एकीकरण का कोई प्रभाव नहीं पड़ा-ईवेंट श्रोता को कभी नहीं बुलाया गया।

यह बहुत अच्छा होगा अगर हम इसके आसपास कुछ दस्तावेज़ जोड़ सकें!

डॉक्स पीआर पहले से ही प्रगति पर है https://github.com/getsentry/sentry-docs/pull/1351/

@OliverJAsh इस परिवर्तन का OnUnhandledRejection एकीकरण को एक नया विकल्प मिला जो आपको इसे क्ली ध्वज की तरह व्यवहार करने की अनुमति देता है।

Sentry.init({
  integrations: [
    new Sentry.Integrations.OnUnhandledRejection({
      mode: 'none'
    })
  ]
});

(अवधारणात्मक रूप से) --unhandled-rejection=none के समान है और वही warn और strict ।
जब आप warn (जो अभी डिफ़ॉल्ट है) का उपयोग करते हैं, तो यह चेतावनी और त्रुटि को स्वयं लॉग करेगा, लेकिन प्रक्रिया को जीवित रखा जाएगा।
जब आप strict , तो यह लॉग करेगा, ईवेंट को कैप्चर करेगा, इसे फ्लश करेगा (इसके डिलीवर होने तक प्रतीक्षा करें) और एग्जिट कोड 1 के साथ प्रक्रिया को मार देगा।

यह समझ आता है। मैं समझता हूं कि एकीकरण नोड ध्वज के व्यवहार को नहीं बदलता है। हालांकि, क्या मैं सिर्फ जांच कर सकता हूं कि मैं सही ढंग से समझता हूं कि नोड ध्वज के संबंध में संतरी कैसे व्यवहार करता है (इस एकीकरण के बाहर)?

बस यह जांचने के लिए कि मैं सही ढंग से समझता हूं: यदि मैं नोड के --unhandled-rejections= सख्त ध्वज का उपयोग करता हूं, तो नोड एक अपवाद के रूप में अप्रतिबंधित अस्वीकृति को उठाएगा, और फिर संतरी उस अपवाद को रोक देगा और इसकी रिपोर्ट करेगा? मुझे लगता है कि मैं यही देख रहा हूं।

@schhumannd FYI करें, आज सुबह हमने @sentry/react-native 1.10.0 जारी किया [संपादित करें: ओह, 1.1.0 होना चाहिए], जो @sentry/browser के नवीनतम संस्करण का उपयोग करने के लिए अपनी निर्भरता को अद्यतन करता है (जिसमें वापसी शामिल है) - true -इसके बजाय- false ऊपर उल्लिखित फिक्स)।

@lobsterkatie @ संतरी/प्रतिक्रिया-मूल की नवीनतम रिलीज़ 1.3.7 प्रतीत होती है। .

तो 1.10.0 स्थापित करने का प्रयास काम नहीं करता है। मैं फिक्स कैसे प्राप्त करूं?

@schhumannd @lobsterkatie का अर्थ है 1.1.0 , क्योंकि यह तब है जब हमने 5.9.0 के @sentry/browser 5.9.0 में अपडेट किया था। लॉगिंग के स्तर को सेट करने वाले हैंडलर विकल्प को @sentry/react-native के हाल के संस्करण में भी ठीक काम करना चाहिए।