Next.js: सर्वर साइड पर लॉग की रिपोर्ट करने के लिए त्रुटियों को कैसे पकड़ें और कैसे संभालें?

क्लाइंट साइड में लॉगिंग त्रुटियों के लिए हम निम्नलिखित कार्य कर रहे हैं:
https://gist.github.com/jgautheron/044b88307d934d486f59ae87c5a5a5a0

यह मूल रूप से सर्वर को त्रुटियां भेजता है, जो अंत में stdout मुद्रित होती हैं और हमारे Docker लॉगिंग ड्राइवर द्वारा पकड़ी जाती हैं।
हमने react-guard साथ SSR त्रुटियों को सफलतापूर्वक पकड़ा है और कोर नेक्स्ट फ़ाइलों को ओवरराइड करने की कोई आवश्यकता नहीं है।

मुझे भी यह समस्या हो रही है। मुझे आश्चर्य है: क्या अगले के handleRequest से अस्वीकृत वादे को वापस करना पर्याप्त होगा? यही है, यहां कोड को बदलने के लिए:

handleRequest (req, res, parsedUrl) {
  // .....snip....

   return this.run(req, res, parsedUrl)
     .catch((err) => {
       if (!this.quiet) console.error(err)
       res.statusCode = 500
       res.end(STATUS_CODES[500])

       // rethrow error to create new, rejected promise 
       throw err;
     })
}

फिर, उपयोगकर्ता कोड में:

const app = nextJs({ dev: process.env.NODE_ENV !== 'production' });
const nextJsHandler = app.getRequestHandler();
const expressApp = express();

app.prepare().then(() => {
   // invoke express middlewares
   // ...

   // time to run next
   expressApp.use(function(req, res, next) {
     nextJsHandler(req, res).catch(e => {
       // use rejected promise to forward error to next express middleware
       next(e)
     })
   });

   // Use standard express error middlewares to handle the error from next
   // this makes it easy to log to sentry etc.
})

@arunoda @rauchg क्या आपको लगता है कि मैंने जो बदलाव तुरंत ऊपर प्रस्तावित किया है वह काम करेगा? अगर ऐसा है, तो पीआर सबमिट करने में खुशी होगी

एक त्रुटि को फिर से फेंकने के लिए सहमत हैं ताकि हम इसके साथ खेल सकें।
इसके अलावा renderToHTML भी फिर से फेंकने की जरूरत है ...

मैं उस स्थिति में भी हूं जहां हम सर्वर और क्लाइंट दोनों तरफ से संतरी जैसी सेवा में त्रुटियां भेजना चाहते हैं।

मेरा मानना ​​​​है कि ऐसी सेवाओं/उपकरणों की सबसे मूल्यवान विशेषता उन मुद्दों की रिपोर्ट करना है जो सबसे अप्रत्याशित हैं, जो मेरे अनुभव में जंगली (यानी क्लाइंट-साइड) में अनजान त्रुटियां हैं। दुर्भाग्य से, जैसा कि पहले संबंधित अंक #2334 में जोर दिया गया था, Next.js के क्लाइंट-साइड हैंडलर इन त्रुटियों को अपने पास रखते हैं, ऐसे अन्य टूल के संतरी को पास करने का कोई संभावित तरीका नहीं है।

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

यहाँ एक नमूना पृष्ठ है जो समस्या को दिखाता है:

import React from 'react';

// Works well in Node 8, but crashes in Chrome<56, Firefox<48, Edge<15, Safari<10, any IE…
const whoops = 'Phew, I made it to the client-side…'.padEnd(80);

export default () => <pre>{whoops}</pre>;

उपरोक्त कोड पूरी तरह से सर्वर-साइड-रेंडर किया जा सकता है और क्लाइंट को वितरित किया जा सकता है, केवल अवांछित सामग्री का फ्लैश बनने के लिए, इससे पहले कि पूरे पृष्ठ को क्लाइंट-साइड पर खतरनाक "एक अप्रत्याशित त्रुटि हुई है" संदेश अधिकांश ब्राउज़रों पर बदल दिया जाए , संतरी (या किसी अन्य सेवा/उपकरण)

यह "त्रुटि निगलने" मानक ऑनरर हैंडलर के किसी भी उत्तोलन को रोकता है, जो कि अधिकांश क्लाइंट-साइड त्रुटि रिपोर्टिंग टूल हुक (या अधिक आधुनिक, लेकिन व्यापक नहीं, गैर-अस्वीकृति पर निर्भर करता है , जो क्लाइंट-साइड की

संभावित क्लाइंट-साइड समाधान

जहां तक ​​मैं बता सकता हूं, इस प्रकार की प्री-रिएक्ट क्लाइंट-साइड त्रुटि Next.js के क्लाइंट/index.js में try / catch ब्लॉक में निगल ली जाती है जहां Component प्रस्तुत करने के बारे में ErrorComponent (वर्तमान में लाइन 67-72 ) के मूल्य पर फिर से असाइन किया गया है।

प्रिय Next.js लेखक और अनुरक्षक, जो प्रस्तुत किया गया है, उसके नियंत्रण के लिए, आपको निम्नलिखित विचारों में से क्या स्वीकार्य/संभव होगा:

• इस तरह की त्रुटि से निपटने के लिए क्लाइंट/index.js में उस catch ब्लॉक में एक हुक पेश करें?
• त्रुटि को एक आतंक/ऑनहैंडल रिजेक्शन हैंडलर को प्रेषित करें, यदि कोई पता चला है?
• त्रुटि को फिर से निकालने का विकल्प प्रदान करें?
• त्रुटि घटक प्रदर्शित न करने का विकल्प प्रदान करें?
• एक कस्टम त्रुटि घटक प्रदर्शित करने का विकल्प प्रदान करें?

इस तरह की त्रुटि से निपटने के लिए क्लाइंट/इंडेक्स.जेएस में उस कैच ब्लॉक में एक हुक पेश करें?
त्रुटि को एक आतंक/ऑनहैंडल रिजेक्शन हैंडलर को प्रेषित करें, यदि कोई पता चला है?

यह ऐसी चीज है जिसके बारे में हमने आंतरिक रूप से बात की है। और हम जल्द ही संबोधित करेंगे।

मैं त्रुटियों की रिपोर्ट करने के लिए Sentry.io का उपयोग कर रहा हूं और जो समाधान हम लागू करते हैं वह है:

1- सर्वर साइड पर रेवेन-नोड को कॉन्फ़िगर करें
2- क्लाइंट साइड पर रैवेंज को कॉन्फ़िगर करें (हमने इसे _document पर बनाया है।

इन दो चरणों के साथ हम क्लाइंट और सर्वर दोनों पर किसी भी अनचाहे अपवाद को पकड़ते हैं।

3- एक _error पेज बनाएं। नेक्स्टज एक बार उत्पन्न होने वाली कोई भी त्रुटि अनुरोध को संभालती है (चाहे क्लाइंट या सर्वर साइड कोई भी हो) उस पृष्ठ को प्रस्तुत किया जाता है। _error पृष्ठ की getInitialProps पद्धति में हम संतरी को त्रुटि की रिपोर्ट करते हैं।

अगर हम क्लाइंट const Raven = require('raven-js'); या सर्वर साइड const Raven = require('raven'); में हैं तो यह तय करने का तरीका है कि रेवेन-नोड या रेवेनज को गतिशील रूप से आयात करके हल किया जाता है या नहीं।
नोट हम webpack कॉन्फ़िगर किया है बंडल नहीं करने के लिए raven मॉड्यूल (सर्वर साइड से एक) को अद्यतन करने के next.config.js के साथ:

const webpack = require('webpack');

module.exports = {
  // Do not show the X-Powered-By header in the responses
  poweredByHeader: false,
  webpack: (config) => {
    config.plugins.push(new webpack.IgnorePlugin(/^raven$/));
    return config;
  },
};

@ acanimal

2- क्लाइंट साइड पर रैवेंज को कॉन्फ़िगर करें (हमने इसे _document.

क्या आप मुझे दिखा सकते हैं कि आपने अपने _document.js पर रेवेन-जेएस को कैसे कॉन्फ़िगर किया? यह मेरे लिए काम नहीं कर रहा है, जब कोई त्रुटि होती है तो संतरी पर कुछ नहीं होता है।

क्या मुझे सभी त्रुटियों को मैन्युअल रूप से _error.js पृष्ठ पर संतरी को भेजने की आवश्यकता है?

// _document constructor
constructor(props) {
    super(props);
    Raven
      .config('...')
      .install();
}

Next.js अभी भी सर्वर पर त्रुटियों को console.error पर आउटपुट करता है जब तक कि आप इसे शांत पर सेट नहीं करते हैं।

संतरी के साथ, आप इस आउटपुट को autoBreadcrumbs को सक्षम कर सकते हैं, और फिर अपने स्वयं के संदेश को मैन्युअल रूप से कैप्चर कर सकते हैं। शीर्षक कम वर्णनात्मक होगा, लेकिन इसमें अभी भी पूर्ण स्टैक ट्रेस होगा।

उदाहरण कार्यान्वयन:

const express = require('express');
const nextjs = require('next');
const Raven = require('raven');

const dev = process.env.NODE_ENV !== 'production';

// Must configure Raven before doing anything else with it
if (!dev) {
  Raven.config('__DSN__', {
    autoBreadcrumbs: true,
    captureUnhandledRejections: true,
  }).install();
}

const app = nextjs({ dev });
const handle = app.getRequestHandler();

const captureMessage = (req, res) => () => {
  if (res.statusCode > 200) {
    Raven.captureMessage(`Next.js Server Side Error: ${res.statusCode}`, {
      req,
      res,
    });
  }
};

app
  .prepare()
  .then(() => {
    const server = express();

    if (!dev) {
      server.use((req, res, next) => {
        res.on('close', captureMessage(req, res));
        res.on('finish', captureMessage(req, res));
        next();
      });
    }

    [...]

    server.get('/', (req, res) => {
      return app.render(req, res, '/home', req.query)
    })

    server.get('*', (req, res) => {
      return handle(req, res)
    })

    server.listen('3000', (err) => {
      if (err) throw err
      console.log(`> Ready on http://localhost:${port}`)
    })
  })
  .catch(ex => {
    console.error(ex.stack);
    process.exit(1);
  });

यह हमारे वास्तविक कोड से अनुकूलित एक बहुत ही काल्पनिक उदाहरण है। मैंने इस रूप में इसका परीक्षण नहीं किया है। टूट जाए तो बता देना।

बेशक, यह अभी भी सबसे अच्छा होगा यदि Next.js उन त्रुटियों को एक्सप्रेस के आसपास भेज सके, ताकि हम बॉक्स से बाहर संतरी/एक्सप्रेस एकीकरण का उपयोग कर सकें।

@tusgavomelo क्षमा करें, देर से उत्तर के लिए।

हमारे पास अपडेट है। हमारे ऐप में हमारे पास एक रेवेन इंस्टेंस प्राप्त करने के लिए ज़िम्मेदार विधि के साथ एक सहायक फ़ाइल है यदि हम क्लाइंट या सर्वर की तरफ हैं।

let clientInstance;
let serverInstance;

const getRavenInstance = (key, config) => {
  const clientSide = typeof window !== 'undefined';

  if (clientSide) {
    if (!clientInstance) {
      const Raven = require('raven-js');  // eslint-disable-line global-require
      Raven.config(key, config).install();
      clientInstance = Raven;
    }

    return clientInstance;
  }

  if (!serverInstance) {
    // NOTE: raven (for node) is not bundled by webpack (see rules in next.config.js).
    const RavenNode = require('raven'); // eslint-disable-line global-require
    RavenNode.config(key, config).install();
    serverInstance = RavenNode;
  }
  return serverInstance;
};

यह कोड सर्वर साइड (जब कोई अनुरोध आता है) और क्लाइंट साइड दोनों चलाता है। हमने जो किया है वह raven पैकेज को बंडल करने से बचने के लिए वेबपैक ( next.config.js फ़ाइल) को कॉन्फ़िगर करना है।

@acanimal क्या आप शायद एक कामकाजी उदाहरण प्रदान कर सकते हैं? ऐसा लगता है कि मुझे पूरा स्टैक ट्रेस नहीं मिल रहा है? या शायद आप अपना _error.js पोस्ट कर सकते हैं?

मैं अपने _error.js RavenInstance.captureException(err) जैसा कुछ कर रहा हूं, लेकिन मुझे यह देखने को नहीं मिलता कि किस प्रकार की त्रुटियां हुईं और साथ ही कहां?

export default class Error extends React.Component {
  static getInitialProps({ res, err }) {
    const RavenInstance = getRavenInstance('__SENTRY__')
    if (!(err instanceof Error)) {
      err = new Error(err && err.message)
    }
    RavenInstance.captureException(err)
    // const statusCode = res ? res.statusCode : err ? err.statusCode : null;

    return { }
  }

  render() {
    return (
      <div>
        <p>An error occurred on server</p>
      </div>
    )
  }
}

इस के बाद से कस्टम लकड़हारा समर्थन के लिए पूछने के लिए जगह की तरह लगता है quiet करने के लिए सेट किया जाना चाहिए false के पुनर्निर्माण और इस तरह देखने से त्रुटियों के शुद्धिकरण, अभी तक केवल व्यावहारिक हैक यहाँ की आवश्यकता है मॉड्यूल पर अगले समाशोधन स्क्रीन को रोकने के लिए quiet को गलत पर सेट करना।

त्रुटियों का विवरण stderr स्ट्रीम पर भी उपलब्ध है।
process.stderr.write = error => yourErrorLog(error);

_अनोर्टोडॉक्स_समाधानों से प्यार होना चाहिए

function installErrorHandler(app) {
  const _renderErrorToHTML = app.renderErrorToHTML.bind(app)
  const errorHandler = rollbar.errorHandler()

  app.renderErrorToHTML = (err, req, res, pathname, query) => {
    if (err) {
      errorHandler(err, req, res, () => {})
    }

    return _renderErrorToHTML(err, req, res, pathname, query)
  }

  return app
}
// ¯\_(ツ)_/¯

कस्टम वेबपैक कॉन्फ़िगरेशन w/o नोड और ब्राउज़र के लिए सही रेवेन कैसे प्राप्त करें का कॉम्पैक्ट संस्करण। @acanimal कमेंट से प्रेरित

// package.json
"browser": {
    "raven": "raven-js"
}

// getRaven.js
const Raven = require('raven')

if (process.env.NODE_ENV === 'production') {
  Raven.config('YOUR_SENTRY_DSN').install()
}

module.exports = Raven

सार

इस समस्या की जांच करने वाले किसी भी व्यक्ति के लिए एक त्वरित पुनर्कथन।

// pages/_error.js
import Raven from 'raven';
...
static async getInitialProps({ store, err, isServer }) {
   if (isServer && err) {
      // https://github.com/zeit/next.js/issues/1852
      // eslint-disable-next-line global-require
      const Raven = require('raven');

      Raven.captureException(err);
    }
    ...

// next.config.js
config.plugins.push(new webpack.IgnorePlugin(/^raven$/));

@acanimal की टिप्पणी के लिए धन्यवाद।

raven (पिछली टिप्पणियों में सुझाए गए वेबपैक के साथ अनदेखा करें) और raven-js दोनों को स्थापित करें, फिर आइसोमोर्फिक रेवेन को तत्काल करने के लिए एक सहायक बनाएं, उदाहरण के लिए lib/raven.js

import Raven from 'raven-js';

// https://gist.github.com/impressiver/5092952
const clientIgnores = {
  ignoreErrors: [
    'top.GLOBALS',
    'originalCreateNotification',
    'canvas.contentDocument',
    'MyApp_RemoveAllHighlights',
    'http://tt.epicplay.com',
    "Can't find variable: ZiteReader",
    'jigsaw is not defined',
    'ComboSearch is not defined',
    'http://loading.retry.widdit.com/',
    'atomicFindClose',
    'fb_xd_fragment',
    'bmi_SafeAddOnload',
    'EBCallBackMessageReceived',
    'conduitPage',
    'Script error.',
  ],
  ignoreUrls: [
    // Facebook flakiness
    /graph\.facebook\.com/i,
    // Facebook blocked
    /connect\.facebook\.net\/en_US\/all\.js/i,
    // Woopra flakiness
    /eatdifferent\.com\.woopra-ns\.com/i,
    /static\.woopra\.com\/js\/woopra\.js/i,
    // Chrome extensions
    /extensions\//i,
    /^chrome:\/\//i,
    // Other plugins
    /127\.0\.0\.1:4001\/isrunning/i, // Cacaoweb
    /webappstoolbarba\.texthelp\.com\//i,
    /metrics\.itunes\.apple\.com\.edgesuite\.net\//i,
  ],
};

const options = {
  autoBreadcrumbs: true,
  captureUnhandledRejections: true,
};

let IsomorphicRaven = null;

if (process.browser === true) {
  IsomorphicRaven = Raven;
  IsomorphicRaven.config(SENTRY_PUBLIC_DSN, {
    ...clientIgnores,
    ...options,
  }).install();
} else {
  // https://arunoda.me/blog/ssr-and-server-only-modules
  IsomorphicRaven = eval("require('raven')");
  IsomorphicRaven.config(
    SENTRY_DSN,
    options,
  ).install();
}

export default IsomorphicRaven;

फिर आप इसे अपने pages/_error.js में उपयोग कर सकते हैं और यह सर्वर और क्लाइंट दोनों तरफ काम करेगा।

import NextError from 'next/error';
import IsomorphicRaven from 'lib/raven';

class MyError extends NextError {
  static getInitialProps = async (context) => {
    if (context.err) {
      IsomorphicRaven.captureException(context.err);
    }
    const errorInitialProps = await NextError.getInitialProps(context);
    return errorInitialProps;
  };
}

export default MyError;

यहां रोलबार सोर्समैप वेपबैक प्लगइन के लिए मेरा पीआर है https://github.com/thredup/rollbar-sourcemap-webpack-plugin/pull/56 Next.js सपोर्ट के साथ :)

@tusgavomelo , क्या आप स्ट्रीम पर मौजूद त्रुटि का उपयोग करने के तरीके के बारे में विस्तार से बता सकते हैं?
"process.stderr.write = error => yourErrorLog (त्रुटि);"

नोड कंसोल में त्रुटि लॉग करने के लिए हमें कोड की यह पंक्ति कहां लिखनी चाहिए?

वह केवल ग्राहक पक्ष है।
Rollbar.error('some error')

https://docs.rollbar.com/docs/javascript

@ टीकी 99 क्या आपके पास @sentry/browser लिए समान समाधान है? शायद संतरी उदाहरण के साथ अद्यतन करें?

@sheerun मैं अब तक raven और raven-js का उपयोग कर रहा हूं। मुझे पता है कि वे शायद पदावनत हो जाएंगे क्योंकि सभी नई सुविधाएं अब @sentry/node और @sentry/browser जोड़ दी गई हैं। बात यह है कि मैंने अभी तक अपनी परियोजनाओं पर इन नए पुस्तकालयों का उपयोग नहीं किया है, लेकिन मैं इसे देखने की कोशिश करूंगा। अगर मेरे पास एक कामकाजी उदाहरण है तो मैं इसके साथ वापस आ जाऊंगा।

विथ-सेंट्री उदाहरण हाल ही में अपडेट किया गया था।

@timneutkens मैं देखता हूं लेकिन यह सर्वर-साइड त्रुटियों का समर्थन नहीं करता है क्योंकि संतरी को ऐप के अंदर प्रारंभ किया गया है जहां सर्वर त्रुटियों को पकड़ने में बहुत देर हो चुकी है। उचित समाधान शायद कहीं @sentry/node उपयोग करेगा

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

मैं @sentry/browser का उपयोग getInitialProps के _error.js में कर रहा हूं और ऐसा लगता है कि यह क्लाइंट और सर्वर-साइड दोनों पर काम कर रहा है। मुझे नहीं पता कि @sentry/browser में सर्वर-साइड सपोर्ट होना चाहिए या नहीं, लेकिन मुझे सेंट्री में इवेंट मिल रहे हैं।

हालांकि मैं कस्टम एक्सप्रेस सर्वर की प्रविष्टि फ़ाइल में Sentry.init() माध्यम से @sentry/node Sentry.init() माध्यम से भी कॉल कर रहा हूं, इसलिए शायद यह कुछ वैश्विक स्थिति सेट कर रहा है जो एसएसआर उपयोग कर रहा है।

यहाँ उस सेटअप का सार है जिसका मैं उपयोग कर रहा हूँ: https://gist.github.com/mcdougal/7bf001417c3dc4b579da224b12776691

दिलचस्प!

यहाँ निश्चित रूप से किसी प्रकार की वैश्विक स्थिति चल रही है (जो थोड़ा डरावना है, और शायद भंगुर और अवांछनीय है)। _error.js में अपने परिवर्तन लागू करना:

• __बिना __ कस्टम सर्वर में संतरी को कॉन्फ़िगर करना:
  
  
  
  • जब विकास मोड या उत्पादन में चल रहा हो (यानी मेरे ऐप के निर्माण के साथ), सर्वर-साइड त्रुटि होने पर संतरी को कुछ भी सूचित नहीं किया जाता है, लेकिन मुझे सर्वर लॉग में कुछ ReferenceError: XMLHttpRequest is not defined त्रुटि मिलती है
  
  
• __कॉन्फ़िगर करने के बाद__ कस्टम सर्वर में संतरी:
  
  
  
  • मेरे सर्वर-साइड अपवादों की रिपोर्ट मिलती है, लेकिन मुझे सेंट्री में एक अजीब Error: Sentry syntheticException रिकॉर्ड किया गया है
  
  

यह समझना अच्छा होगा कि आधिकारिक समाधान क्या है। नेक्स्ट के डॉक्स अब एक कस्टम <App> घटक का उपयोग करने की सलाह देते हैं, और यही "सेंट्री के साथ" उदाहरण करता है, लेकिन यह केवल क्लाइंट साइड के लिए काम करता है।

पहली बार ऐप रेंडर होने तक त्रुटि रिपोर्टिंग निश्चित रूप से नहीं होगी। अगला रास्ता पहले विफल हो सकता है जैसे पेज को प्रस्तुत करते समय। हो सकता है कि संयोग से यह कुछ मामलों में काम करता हो जब ऐप पहली बार सर्वर साइड पर प्रस्तुत किया गया हो, लेकिन निश्चित रूप से यह पूर्ण समाधान नहीं है।

संतरी उदाहरण मेरे लिए @timneutkens के लिए भी काम नहीं करता है। प्रोजेक्ट चलाना और मेरे वास्तविक डीएसएन के साथ इसका परीक्षण करना 400 प्रतिक्रिया देता है और संतरी (एपीआई के संस्करण 7) को कुछ भी नहीं मिलता है।

{"error":"Bad data reconstructing object (JSONDecodeError, Expecting value: line 1 column 1 (char 0))"}

@mcdougal मेरे काम नहीं आया। वैश्विक सर्वर-साइड सेटअप होना पहले से ही बहुत अच्छा नहीं था जो किसी भी तरह क्लाइंट तक बुलबुले हो, लेकिन उस हैक के साथ भी मुझे 301 प्रतिक्रियाएं मिलेंगी।

मैं नहीं देखता कि मेरे संतरी स्वयं-होस्ट किए गए सेटअप में गलत कॉन्फ़िगरेशन कैसे हो सकता है, क्योंकि कई विकल्प नहीं हैं और यह कई परियोजनाओं पर चल रहा है।

मैं @sentry/browser का उपयोग उसी तरह कर रहा हूं जैसे कि संतरी उदाहरण में इसकी अनुशंसा की जाती है, और ऐसा लगता है कि सर्वर और क्लाइंट दोनों से मेरी संतरी को त्रुटियां भेज रहा है। मेरे पास कोई विशेष कॉन्फ़िगरेशन नहीं है, उदाहरण के समान कोड है।

@ जौनी क्या आप सुनिश्चित हैं कि यह सर्वर से भेज रहा है? आपने इसका परीक्षण कैसे किया? उदाहरण का रीडमी यह भी बताता है कि यह सर्वर पर काम नहीं करेगा।

@timrogers हाँ वास्तव में मेरा बुरा है, मुझे लगता है कि सर्वर से एक परीक्षण त्रुटि आ रही थी लेकिन वास्तव में क्लाइंट से ट्रिगर किया गया था :(

ऐसा लगता है कि संतरी के साथ वर्तमान उदाहरण getInitialProps में फेंकने वाली त्रुटियों को नहीं पकड़ता है, केवल एप्लिकेशन के पेड़ प्रस्तुत करने वाले हैं .. मेरे मामले में अधिकांश त्रुटियां getInitialProps से हैं।

@sheerun क्या आप ऊपर दिए गए मैकडॉगल वर्कअराउंड को आजमा सकते हैं? यह सही नहीं है (अजीब सिंथेटिक संतरी त्रुटियां) लेकिन मुझे लगता है कि इसमें सभी त्रुटियां हैं और मैं जानना चाहता हूं कि यह सच नहीं है। अगर यह सच है, तो संभवतः संतरी उदाहरण को इसके साथ अद्यतन करने की आवश्यकता है जब तक कि Next.js इसे बेहतर तरीके से करने के बारे में सलाह नहीं दे सकता (आदर्श रूप से इसे सर्वर.जेएस संतरी त्रुटि हैंडलर को छोड़ दिया नहीं जाता है?)

ऐसा लगता है कि यह थोड़े दो प्रमुख मुद्दों के साथ काम करता है:

1. शायद इसलिए कि एसिंक्रोनस सर्वर-साइड कोड को अनावश्यक रूप से रीजेनरेटर कोड में संकलित किया जाता है, उत्पादन में सर्वर-साइड स्टैकट्रेस को अक्सर आंतरिक/प्रक्रिया/next_tick.js पर छोटा कर दिया जाता है और त्रुटि का कोई कारण बिल्कुल भी दिखाई नहीं देता है।
2. अगले अनुरोध हैंडलर को कॉल करने से पहले त्रुटियों को फेंकने पर त्रुटि प्रबंधन काम नहीं करेगा (उदाहरण के लिए कस्टम सर्वर कोड में)

असल में आगे के परीक्षण के बाद किसी कारण से कस्टम त्रुटि के प्रारंभिकप्रॉप्स उत्पादन में फायरिंग भी नहीं कर रहे हैं जब उदाहरण के लिए कस्टम _app के getInitialProps के अंदर त्रुटि होती है ..

हाँ, कुछ दिनों के अपने प्रयास के साथ दौड़ने के बाद मुझे निश्चित रूप से कुछ अजीब व्यवहार हो रहा है। ऐसा लगता है कि हम जिन मुख्य समस्याओं का सामना कर रहे हैं वे हैं:

1. सीएसआर के लिए @sentry/browser और एसएसआर के लिए @sentry/node आयात करना
2. सीएसआर और एसएसआर दोनों के लिए हमेशा ट्रिगर होने वाली त्रुटि से निपटने के लिए जगह खोजना

मैं #1 को हल करने के लिए आलसी आयात और वैश्विक स्थिति का उपयोग करने की कोशिश करने की सोच रहा हूं, कुछ ऐसा

const sentryInitialized = false;

# Inside some trigger point
const Sentry = ssr ? eval(`require('@sentry/node')`) : eval(`require('@sentry/browser')`);
if (!sentryInitialized) {
  Sentry.init({dsn: SENTRY_DSN});
}
Sentry.captureException(err);

हो सकता है कि नेक्स्ट के डायनामिक इंपोर्ट का इस्तेमाल किया जा सके, लेकिन मैं अभी तक उनसे परिचित नहीं हूं। मुझे यह भी यकीन नहीं है कि हर बार त्रुटि प्रबंधन कोड ट्रिगर होने पर require पर कॉल करने का असर पड़ता है। अगर मैं इसे आज़माता हूं तो मैं अपडेट करूंगा।

जहां तक ​​​​समस्या #2 , ऐसा लगता है कि संभावनाएं हैं:

1. _app.componentDidCatch , जो SSR के लिए सक्रिय नहीं है
2. _error.getInitialProps , जिसमें बहुत सी समस्याएं हैं
3. ...कुछ और? क्या हम नेक्स्ट सर्वर हैंडलर फंक्शन में SSR के लिए कुछ कर सकते हैं?

मेरी आंत की भावना यह है कि नेक्स्ट से पहले सेंट्री के एरर हैंडलर को इंजेक्ट करके सर्वर पर ऐसा करने का एक तरीका होगा, लेकिन मैंने इसे अभी तक नहीं दिया है।

फिलहाल, ऐसा करने में आपकी सहायता के लिए अगला कोई हुक प्रदान नहीं करता है। अगर हमने पाया कि यह काम करता है, तो हम उन्हें जोड़ सकते हैं

एक जोखिम है कि यह काम नहीं करेगा क्योंकि अगला बहुत जल्दी पकड़ता है, हालांकि।

@mcdougal आह &#!% मैं बहुत खुश था जब आपका कामकाज हमें उत्पादन में लाने के लिए आवश्यक संतरी क्लाइंट/सर्वर कवरेज की जांच करने के लिए पर्याप्त हो सकता था।

मेरी पूरी अज्ञानता को क्षमा करें, लेकिन क्या हमें इसके त्रुटि हैंडलर को सशर्त रूप से अक्षम करने की अनुमति देने के लिए बस आवश्यकता है ताकि नोडज संतरी त्रुटि हैंडलर पहला बन जाए? next.config.js में कुछ ध्वज "disableErrorHandler" कहलाते हैं?

@Enalmada मुझे नहीं लगता कि आप अगला त्रुटि हैंडलर अक्षम करना चाहते हैं क्योंकि यह वह होगा जो एक अच्छा त्रुटि पृष्ठ प्रस्तुत करता है। आप इससे पहले अन्य मिडलवेयर डालना चाहते हैं। मुझे लगता है कि यह काम करेगा, लेकिन मुझे इसे आजमाने की जरूरत है।

यहां तक ​​​​कि उस निश्चित के साथ, मुझे अभी भी क्लाइंट-साइड त्रुटि प्रबंधन कार्यों की तरह महसूस नहीं होता है और साथ ही मुझे उम्मीद है :(

यह पूरा मुद्दा शर्म की बात है और यह वास्तव में उत्पादन में अगला सुरक्षित रूप से चलाने के लिए एक अवरोधक है।

FYI करें मैं हर जगह @sentry/node आयात करता हूं और निम्नलिखित को next.config.js में डालता हूं:

        if (!isServer) {
          config.resolve.alias['@sentry/node$'] = '@sentry/browser'
        }

जो @mcdougal . के eval से बेहतर हो सकता है

कस्टम _app घटक और त्रुटि प्रबंधन के बारे में मेरे अतिरिक्त नोट्स यहां दिए गए हैं:

1. _app.js का उपयोग सभी पृष्ठों के लिए किया जाता है, जिसमें _error.js या 404 जैसे पृष्ठ शामिल हैं, इसलिए आप वास्तव में यह सुनिश्चित करना चाहते हैं कि जब ctx.err इसे पास किया जाता है तो कोई त्रुटि नहीं होती है।
2. ऐप के getInitialProps में Component.getInitialProps को कॉल करना न भूलें क्योंकि यह _error.js getInitialProps को कॉल करने से रोकेगा ( ctx.err मौजूद होने पर भी इसे कॉल करें)

class MyApp extends App {
  static async getInitialProps (appContext) {
    const { Component, ctx } = appContext
    if (ctx.err) {
      if (Component.getInitialProps) {
        pageProps = await Component.getInitialProps(ctx)
      }
      return { error: true, pageProps }
    }
    // here code that can throw an error, and then:
    if (Component.getInitialProps) {
      pageProps = await Component.getInitialProps(ctx)
    }
    return { pageProps }
  }
  render() {
    if (this.props.error) return super.render()
    // rest of code that can throw an error
  }
}

अब तक मुझे अगली.जेएस में एक बहुत ही नाजुक प्रक्रिया में त्रुटि रिपोर्टिंग ठीक से सेट अप मिल रही है :(

धन्यवाद @sheerun जो सही दिशा की ओर एक अच्छा पड़ाव लगता है। मैं सहमत हूं कि अगले में त्रुटि प्रबंधन अभी इष्टतम नहीं है, कुछ एक्स्टेंसिबल मॉड्यूल/मिडलवेयर जोड़े गए देखना बहुत अच्छा होगा ताकि हम इस पर त्रुटि प्रबंधन आदि जोड़ सकें।

संतरी जैसे आइसोमोर्फिक पुस्तकालयों की कमी भी चीजों को जटिल बना रही है, क्योंकि इसका मतलब है कि हम अपने घटकों में पुस्तकालय को सरल आयात नहीं कर सकते हैं, हमें इसे रनटाइम पर गतिशील रूप से करने की आवश्यकता है ताकि हमेशा यह जांचा जा सके कि त्रुटि सर्वर या ब्राउज़र की तरफ उठाई गई है या नहीं।

क्या इस मुद्दे पर कोई अपडेट है? मैंने अब तक जो कोशिश की वह निम्नलिखित है: मैंने अपना सभी ट्रैकिंग कोड _app.js . में स्थानांतरित कर दिया है

constructor(args: any) {
        super(args)
        Sentry.init({
            dsn: 'blah',
            environment: 'local',
        })
        Sentry.configureScope(scope => {
            scope.setTag('errorOrigin', isServer ? 'SSR' : 'Client')
        })
    }

    static async getInitialProps({ Component, router, ctx }: any) {
        let pageProps = {}

        try {
            if (Component.getInitialProps) {
                pageProps = await Component.getInitialProps(ctx)
            }
        } catch (error) {
            // console.log('we caught an error')
            console.log(error)
            Sentry.captureException(error)
            throw error
        }

        return { pageProps }
    }

साथ में @sheerun से अगला . सर्वर में संतरी को इनिशियलाइज़ करना भी if (!isServer) { config.resolve.alias['@sentry/node$'] = '@sentry/browser' }
ऐसा लगता है कि क्लाइंट साइड पर सभी त्रुटियों को ट्रैक करता है, लेकिन सर्वर की तरफ यह केवल पहली त्रुटि को ट्रैक करता है जो सर्वर के पुनरारंभ होने के बाद होता है। हालांकि बाद में सर्वर पर त्रुटियों को ट्रैक नहीं किया जाता है। इस दृष्टिकोण के साथ मेरे पास लॉग में कोई सिंथेटिक त्रुटि नहीं है, लेकिन केवल वास्तविक त्रुटियां हैं।

फिर भी यह मेरे लिए काफी हैकी लगता है और चूंकि सर्वर साइड ट्रैकिंग केवल पहली बार काम कर रही है, यह अभी भी अनुपयोगी है।

मैंने इस भाग को संतरी उदाहरण से भी जोड़ा है

    componentDidCatch(error: any, errorInfo: any) {
        // if (process.env.FIAAS_NAMESPACE !== undefined) {
        Sentry.configureScope(scope => {
            Object.keys(errorInfo).forEach(key => {
                scope.setExtra(key, errorInfo[key])
            })
        })
        Sentry.captureException(error)
        console.log('componentDidCatch')

        // This is needed to render errors correctly in development / production
        super.componentDidCatch(error, errorInfo)
        // }
    }

लेकिन मुझे पूरा यकीन नहीं है कि इसकी आवश्यकता है

मेरे मामले में मुद्दों के बिना काम करता है। साथ ही आपको संतरी में प्रवेश नहीं करना चाहिए
_app.js कंस्ट्रक्टर लेकिन इस वर्ग के बाहर पूरी तरह से

बुध, नवम्बर 21, 2018 पर abraxxas 2:53 pm पर [email protected] लिखा है:

क्या इस मुद्दे पर कोई अपडेट है? मैंने अब तक जो कोशिश की वह निम्नलिखित है: I
हमारे सभी ट्रैकिंग कोड को _app.js . में स्थानांतरित कर दिया

`
कंस्ट्रक्टर (तर्क: कोई भी) {
सुपर (तर्क)
संतरी.इनिट({
डीएसएन: 'ब्लाह',
पर्यावरण: 'स्थानीय',
})
संतरी.कॉन्फ़िगरस्कोप (दायरा => {
स्कोप.सेटटैग ('एररऑरिजिन', आईसर्वर? 'एसएसआर': 'क्लाइंट')
})
}

स्थैतिक async getInitialProps ({घटक, राउटर, ctx}: कोई भी) {
चलो पेजप्रॉप्स = {}

try {
    if (Component.getInitialProps) {
        pageProps = await Component.getInitialProps(ctx)
    }
} catch (error) {
    // console.log('we caught an error')
    console.log(error)
    Sentry.captureException(error)
    throw error
}

return { pageProps }

}

`

@sheerun . से next.config.js जोड़ के साथ मिलकर
https://github.com/sheerun और सर्वर में संतरी प्रारंभ करना। जेएस भी अगर
(!isServer) { config.resolve.alias['@sentry/node$'] = '@sentry/browser' }
ऐसा लगता है कि क्लाइंट साइड पर सभी त्रुटियों को ट्रैक किया गया है, लेकिन सर्वर की तरफ
ऐसा लगता है कि यह केवल पहली त्रुटि को ट्रैक करता है जो पुनरारंभ होने के बाद होता है
सर्वर। हालांकि बाद में सर्वर पर त्रुटियों को ट्रैक नहीं किया जाता है। इसके साथ ही
दृष्टिकोण मेरे पास लॉग में कोई सिंथेटिक त्रुटि नहीं है, लेकिन केवल वास्तविक त्रुटियां हैं।

फिर भी यह मेरे लिए काफी हैकी लगता है और चूंकि सर्वर साइड ट्रैकिंग है
केवल पहली बार काम कर रहा है यह अभी भी अनुपयोगी है।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/zeit/next.js/issues/1852#issuecomment-440668980 , या म्यूट करें
सूत्र
https://github.com/notifications/unsubscribe-auth/AAR2DeIhoOj6PdWRA2VqiEZyrO5Jui8vks5uxVrHgaJpZM4NOQlp
.

मैंने इसे पहले से ही बाहर ले जाने की कोशिश की और अभी भी वही व्यवहार। @sheerun क्या आप शायद अपने सेटअप का न्यूनतम सार पोस्ट कर सकते हैं? मैंने इसे आपके द्वारा प्रदान किए गए स्निपेट के साथ स्थापित करने का प्रयास किया और मैं इसे काम पर नहीं ला सकता। जो कुछ मैं अपेक्षा करता था उसके लिए पूरी बात अत्यधिक जटिल लगती है :( क्या आप सर्वर पर संतरी शुरू कर रहे हैं या केवल कक्षा के बाहर _app.js में हैं?

मैं आधिकारिक संतरी उदाहरण अपडेट करूंगा लेकिन मुझे डर है कि इसे "बहुत जटिल" के रूप में खारिज कर दिया जाएगा, हालांकि जब मुझे समय मिलेगा तो मैं कुछ पोस्ट करने का प्रयास कर सकता हूं ..

@sheerun यहां तक ​​​​कि आधिकारिक उदाहरण को अपडेट करने का प्रयास भी बहुत महत्वपूर्ण होगा। मुझे लगता है कि यह विलय हो जाएगा यदि यह वास्तव में न्यूनतम जटिलता है जो संतरी ssr को SyntheticErrors के बिना काम करने या केवल पहली सर्वर त्रुटि को रिकॉर्ड करने के लिए आवश्यक है। फिर हम इसे बेहतर बनाने के तरीकों का पता लगाने के लिए वहां से जा सकते हैं या नेक्स्टज कोर सुधार या संतरी आइसोमोर्फिक समर्थन पर जोर दे सकते हैं।

यहाँ यह जाता है .. https://github.com/zeit/next.js/pull/5727

तो अब जब हमारे पास एक आवश्यक रूप से जटिल कामकाजी उदाहरण है, तो स्थिति को सुधारने के लिए अगले कदम क्या हैं:

• खुले संतरी मुद्दों पर तौलना (कोई गुम है?):
  https://github.com/getsentry/sentry-javascript/issues/1762#issuecomment -442778751
  https://github.com/getsentry/sentry-javascript/issues/1622
  https://github.com/getsentry/sentry-javascript/issues/951
• @sheerun आप उल्लेख करते हैं next.js सर्वर और ऐप के लिए प्लगइन्स बनाने में मदद कर सकता है। क्या कोई फीचर टिकट उसके आसपास कहीं केंद्रित है?
• nextjs टीम त्रुटियों को आसान बनाने के लिए विधि के साथ मदद कर सकती है:
  https://github.com/zeit/next.js/issues/1852#issuecomment -337573921
  https://github.com/zeit/next.js/issues/1852#issuecomment -427124032

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

next.browser.js के लिए next.js ऐप या दस्तावेज़ घटकों के लिए डेकोरेटर जैसे कॉन्फ़िगरेशन को परिभाषित कर सकता है। इस तरह मैं पूरी तरह से एक प्लगइन के रूप में संतरी एकीकरण को लागू कर सकता था।

संपादित करें: मुझे नहीं पता कि इसके लिए टिकट है या नहीं, लेकिन मुझे लगता है कि @timneutkens पहले से ही अगले सर्वर को अलग-अलग पैकेजों में

module.exports = {
  server: server => {
    server.use(Sentry.Handlers.errorHandler())
  }
}

मैंने ऐसे एपीआई के प्रस्ताव को #6922 . में लागू किया है

यह कस्टम सर्वर कोड में डेकोरेटर जोड़ने की अनुमति देता है क्योंकि अनुबंध को एक में बदल दिया जाता है जो स्वचालित रूप से .listen() कॉल नहीं करता है, इसलिए यह next.js को तत्काल करने से पहले इसे और सजाने की अनुमति देता है

मुझे with-sentry उदाहरण का उपयोग करने में बहुत परेशानी हो रही थी, इसलिए मैंने एक और अधिक सरल उदाहरण के लिए एक पीआर खोला। इसमें सभी घंटियाँ और सीटी नहीं हैं, लेकिन यह मेरे लिए काम कर रहा है।

https://github.com/zeit/next.js/pull/7119

इसे कस्टम _document.js में आज़माएं:

import React from "react";
import Document, {
  Html,
  Head,
  Main,
  NextScript,
} from "next/document";
import { NodeClient } from "@sentry/node";

const { default: getConfig } = require("next/config");
const { publicRuntimeConfig: { sentryDSN } } = getConfig();

let sentry = null;
if (sentryDSN) {
  sentry = new NodeClient({ dsn: sentryDSN });
}

export default class MyDocument extends Document {
  static async getInitialProps(ctx) {
    const initialProps = await Document.getInitialProps(ctx);
    if (ctx.err && sentry) sentry.captureException(ctx.err);
    return { ...initialProps };
  }

  render() {
    return (
      <Html>
        <Head />
        <body>
          <Main />
          <NextScript />
        </body>
      </Html>
    );
  }
}

और यह कस्टम _app.js :

import * as Sentry from "@sentry/browser";

const { default: getConfig } = require("next/config");
const { publicRuntimeConfig: { sentryDSN } } = getConfig();

if (sentryDSN) {
  Sentry.init({ dsn: sentryDSN });
}

इससे मुझे मदद मिलती है।

टीबीएच मैं बहुत उलझन में हूं कि अगले के लिए त्रुटियों को पकड़ने के लिए सही स्थान कौन से हैं। जेएस अभी हैं। _app.tsx, _error.tsx और _document.tsx हैं, कुछ टिप्पणियां कह रही हैं कि कुछ सामान _error.tsx में पकड़े जाने चाहिए (जैसे: https://github.com/zeit/next.js/pull/5727/files #r235981700) लेकिन वर्तमान उदाहरण या तो _app.tsx या _app और _document का उपयोग करते हैं।

मैंने अब दोनों तरीकों की कोशिश की और ऐसा लगता है कि ssr के दौरान होने वाली कुछ त्रुटियां मेरे लिए पकड़ में नहीं आ रही हैं। त्रुटियों की जाँच के लिए अब कौन से स्थान सही हैं? मेरे लिए सबसे तार्किक एक _app के घटकडिडकैच और _error के getInitialProps में जांच करना प्रतीत होता है क्योंकि यह त्रुटियों के मामलों में परोसा जा रहा है। मैं _दस्तावेज़ में संपूर्ण process.on भाग के बारे में थोड़ा भ्रमित हूँ

क्या कोई और गहराई से ज्ञान रखने वाला कृपया इस प्रश्न को हल कर सकता है?

@abraxxas process.on में _document.js सर्वर पर होने वाली त्रुटियों को पकड़ रहा है। पुनर्कथन के रूप में,

• _document.js केवल _सर्वर-साइड_ है और प्रारंभिक सर्वर-साइड प्रदान किए गए दस्तावेज़ मार्कअप को बदलने के लिए उपयोग किया जाता है।
• _app.js केवल _client-side_ है और पृष्ठों को प्रारंभ करने के लिए उपयोग किया जाता है।

इसलिए, जब सर्वर पर कोई त्रुटि होती है तो उसे process.on माध्यम से संतरी को एक त्रुटि फेंकनी चाहिए और फिर क्लाइंट डिफ़ॉल्ट त्रुटि पृष्ठ या _error.js प्रस्तुत करेगा।

उम्मीद है कि इससे मदद मिलेगी: https://leerob.io/blog/configuring-sentry-for-nextjs-apps/

_app.js केवल क्लाइंट-साइड नहीं है, हालांकि componentDidCatch है

@timneutkens ठीक है, यह मेरे दिमाग को थोड़ा सा अपडेट किए गए हैं । क्या आप बता सकते हैं कि कैसे _app.js केवल अधिक विस्तार से क्लाइंट-साइड नहीं है?

@timneutkens क्या आप शायद समझा सकते हैं कि आप त्रुटियों को कहाँ और क्यों

@timneutkens ठीक है, यह मेरे दिमाग को थोड़ा सा अपडेट किए गए हैं । क्या आप बता सकते हैं कि कैसे _app.js केवल अधिक विस्तार से क्लाइंट-साइड नहीं है?

हैलो लीरोब!
मैंने अभी आपके उदाहरण के मर्ज अनुरोध पर एक प्रश्न पोस्ट किया है:
https://github.com/zeit/next.js/pull/7360#issuecomment -514318899

उस प्रश्न को जोड़ना ... मैंने सर्वर साइड पर रेंडर() में एक त्रुटि फेंकने की भी कोशिश की (मैंने राज्य को raiseErrorInRender के साथ शुरू किया: सच है, इसलिए पहला रेंडर, जो सर्वर पक्षीय है, पहले से ही एक त्रुटि फेंक देगा), और वह त्रुटि भी संतरी द्वारा कब्जा नहीं किया गया था।

क्या आपने अपने आवेदन में इसका परीक्षण किया है, और क्या वे सर्वर पक्षीय त्रुटियां वास्तव में कैप्चर की जा रही हैं? मैं अगला 9 का उपयोग कर रहा हूं।

यदि वास्तव में ऐसा है, और केवल क्लाइंट साइड त्रुटियों को पकड़ा जा रहा है, तो _document.js फ़ाइल को ओवरराइड करने का कोई कारण नहीं होगा।

किसी भी सहायता के लिए अग्रिम रूप से धन्यवाद!

@timneutkens ठीक है, यह मेरे दिमाग को थोड़ा सा अपडेट किए गए हैं । क्या आप बता सकते हैं कि कैसे _app.js केवल अधिक विस्तार से क्लाइंट-साइड नहीं है?

आपके प्रश्न का उत्तर देते हुए, _app वह जगह है जहां पृष्ठों को प्रारंभ करने के लिए एक ऐप घटक परिभाषित किया गया है। हम इसे ऐसे मामलों में ओवरराइड करेंगे जैसे पृष्ठ परिवर्तनों के बीच एक स्थायी लेआउट की आवश्यकता (सभी पृष्ठ समान _app का उपयोग करते हैं), या रेडक्स का उपयोग करने के लिए। तो, सर्वर साइड पर होने वाला पहला रेंडर भी _app की सामग्री को प्रस्तुत करेगा (यह केवल क्लाइंट साइड नहीं है)।

उस प्रश्न को जोड़ना ... मैंने सर्वर साइड पर रेंडर() में एक त्रुटि फेंकने की भी कोशिश की (मैंने राज्य को raiseErrorInRender के साथ शुरू किया: सच है, इसलिए पहला रेंडर, जो सर्वर पक्षीय है, पहले से ही एक त्रुटि फेंक देगा), और वह त्रुटि भी संतरी द्वारा कब्जा नहीं किया गया था।

क्या आपने उस त्रुटि को संतरी में दिखाने के लिए किसी अन्य तरीके से प्रबंधित किया है? मैंने इसे _error के getInitialProps में कैप्चर करने का प्रयास किया लेकिन यह संतरी में कुछ भी नहीं दिखाता है। वर्तमान में मुझे सर्वर पर त्रुटियों को पकड़ने का एक विश्वसनीय तरीका नहीं मिला है, उनमें से कुछ (ज्यादातर अगर वे एपीआई विफलताओं से जुड़े हैं) तो वे दिखाई देते हैं, लेकिन मैं संतरी में दिखाने के लिए त्रुटि परीक्षण से एक साधारण त्रुटि प्राप्त करने में कामयाब नहीं हुआ हूं।

उस प्रश्न को जोड़ना ... मैंने सर्वर साइड पर रेंडर() में एक त्रुटि फेंकने की भी कोशिश की (मैंने राज्य को raiseErrorInRender के साथ शुरू किया: सच है, इसलिए पहला रेंडर, जो सर्वर पक्षीय है, पहले से ही एक त्रुटि फेंक देगा), और वह त्रुटि भी संतरी द्वारा कब्जा नहीं किया गया था।

क्या आपने उस त्रुटि को संतरी में दिखाने के लिए किसी अन्य तरीके से प्रबंधित किया है? मैंने इसे _error के getInitialProps में कैप्चर करने का प्रयास किया लेकिन यह संतरी में कुछ भी नहीं दिखाता है। वर्तमान में मुझे सर्वर पर त्रुटियों को पकड़ने का एक विश्वसनीय तरीका नहीं मिला है, उनमें से कुछ (ज्यादातर अगर वे एपीआई विफलताओं से जुड़े हैं) तो वे दिखाई देते हैं, लेकिन मैं संतरी में दिखाने के लिए त्रुटि परीक्षण से एक साधारण त्रुटि प्राप्त करने में कामयाब नहीं हुआ हूं।

दुर्भाग्य से नहीं। मुझे लगता है कि मैं जिस समाधान को लागू करने जा रहा हूं, वह क्लाइंट साइड पर होने वाली त्रुटियों को पकड़ने के लिए मेरे टेम्पलेट के रूप में उदाहरण (ओवरराइड _document.js फ़ाइल को घटाकर) का उपयोग करना है, क्योंकि वे वही हैं जिन पर मेरा कोई नियंत्रण और तरीका नहीं है के बारे में जानें, जब तक कि उपयोगकर्ता मुझे रिपोर्ट न करें। सर्वर की तरफ, मुझे लगता है कि मैं किसी भी लॉग लाइन को सीधे लॉग फ़ाइल पर रीडायरेक्ट कर दूंगा। यह निश्चित रूप से सबसे अच्छा समाधान नहीं है क्योंकि मैं एक ही स्थान पर सभी त्रुटियां रखना चाहता था, लेकिन ऐसा करने से मुझे कम से कम किसी भी त्रुटि के बारे में जानकारी होगी जो आवेदन पर हो सकती है।

उसके बारे में क्या ख़याल है? धन्यवाद!

उस प्रश्न को जोड़ना ... मैंने सर्वर साइड पर रेंडर() में एक त्रुटि फेंकने की भी कोशिश की (मैंने राज्य को raiseErrorInRender के साथ शुरू किया: सच है, इसलिए पहला रेंडर, जो सर्वर पक्षीय है, पहले से ही एक त्रुटि फेंक देगा), और वह त्रुटि भी संतरी द्वारा कब्जा नहीं किया गया था।

क्या आपने उस त्रुटि को संतरी में दिखाने के लिए किसी अन्य तरीके से प्रबंधित किया है? मैंने इसे _error के getInitialProps में कैप्चर करने का प्रयास किया लेकिन यह संतरी में कुछ भी नहीं दिखाता है। वर्तमान में मुझे सर्वर पर त्रुटियों को पकड़ने का एक विश्वसनीय तरीका नहीं मिला है, उनमें से कुछ (ज्यादातर अगर वे एपीआई विफलताओं से जुड़े हैं) तो वे दिखाई देते हैं, लेकिन मैं संतरी में दिखाने के लिए त्रुटि परीक्षण से एक साधारण त्रुटि प्राप्त करने में कामयाब नहीं हुआ हूं।

दुर्भाग्य से नहीं। मुझे लगता है कि मैं जिस समाधान को लागू करने जा रहा हूं, वह क्लाइंट साइड पर होने वाली त्रुटियों को पकड़ने के लिए मेरे टेम्पलेट के रूप में उदाहरण (ओवरराइड _document.js फ़ाइल को घटाकर) का उपयोग करना है, क्योंकि वे वही हैं जिन पर मेरा कोई नियंत्रण और तरीका नहीं है के बारे में जानें, जब तक कि उपयोगकर्ता मुझे रिपोर्ट न करें। सर्वर की तरफ, मुझे लगता है कि मैं किसी भी लॉग लाइन को सीधे लॉग फ़ाइल पर रीडायरेक्ट कर दूंगा। यह निश्चित रूप से सबसे अच्छा समाधान नहीं है क्योंकि मैं एक ही स्थान पर सभी त्रुटियां रखना चाहता था, लेकिन ऐसा करने से मुझे कम से कम किसी भी त्रुटि के बारे में जानकारी होगी जो आवेदन पर हो सकती है।

उसके बारे में क्या ख़याल है? धन्यवाद!

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

इस थ्रेड के लोगों की दिलचस्पी https://github.com/zeit/next.js/pull/8684 और संबंधित बग्स में हो सकती है। इसमें हैंडल न किए गए अपवादों के 12 अलग-अलग परीक्षण हैं, जिन्हें आप यह समझने के लिए खेल सकते हैं कि Next.js आपके लिए कौन से अपवादों को संभालता है और क्या नहीं।

इस मुद्दे के बारे में कोई खबर?

मेरे समाधान का उपयोग है redux नोड बचाने में डेटा त्रुटि लाने state तो फिर में componentDidMount के _app.js उपयोगकर्ता या पोस्ट त्रुटि अनुरोध के लिए क्या कुछ (चेतावनी बैकएंड के लिए)।
कोड वहाँ है next-antd-scaffold_server-error ।

========> राज्य

import {
  SERVER_ERROR,
  CLEAR_SERVER_ERROR
} from '../../constants/ActionTypes';

const initialState = {
  errorType: []
};

const serverError = (state = initialState, { type, payload }) => {
  switch (type) {
    case SERVER_ERROR: {
      const { errorType } = state;
      errorType.includes(payload) ? null : errorType.push(payload);
      return {
        ...state,
        errorType
      };
    }
    case CLEAR_SERVER_ERROR: {
      return initialState;
    }
    default:
      return state;
  }
};

export default serverError;

=======> क्रिया

import {
  SERVER_ERROR
} from '../../constants/ActionTypes';

export default () => next => action => {
  if (!process.browser && action.type.includes('FAIL')) {
    next({
      type: SERVER_ERROR,
      payload: action.type 
    });
  }
  return next(action);
};

=======> _app.js

...
componentDidMount() {
    const { store: { getState, dispatch } } = this.props;
    const { errorType } = getState().serverError;
    if (errorType.length > 0) {
      Promise.all(
        errorType.map(type => message.error(`Node Error, Code：${type}`))
      );
      dispatch(clearServerError());
    }
  }
...

https://github.com/zeit/next.js/issues/1852#issuecomment -353671222 के लिए धन्यवाद मुझे सर्वर-साइड रोलबार त्रुटि रिपोर्टिंग के साथ काम करने का एक

_अनोर्टोडॉक्स_समाधानों से प्यार होना चाहिए

function installErrorHandler(app) {
  const _renderErrorToHTML = app.renderErrorToHTML.bind(app)
  const errorHandler = rollbar.errorHandler()

  app.renderErrorToHTML = (err, req, res, pathname, query) => {
    if (err) {
      errorHandler(err, req, res, () => {})
    }

    return _renderErrorToHTML(err, req, res, pathname, query)
  }

  return app
}
// ¯\_(ツ)_/¯

इस विधि को 404 त्रुटि पर लागू नहीं किया जा सकता है क्योंकि त्रुटि तर्क 404 त्रुटि होने पर शून्य होने वाला है।

मैंने इसे इलास्टिक एपीएम नोड क्लाइंट के लिए हल किया (https://www.npmjs.com/package/elastic-apm-node)

रुचि रखने वाले किसी के लिए:

next.config.js :

webpack: (config, { isServer, webpack }) => {
      if (!isServer) {
        config.node = {
          dgram: 'empty',
          fs: 'empty',
          net: 'empty',
          tls: 'empty',
          child_process: 'empty',
        };

        // ignore apm (might use in nextjs code but dont want it in client bundles)
        config.plugins.push(
          new webpack.IgnorePlugin(/^(elastic-apm-node)$/),
        );
      }

      return config;
} 

फिर _error.js func प्रस्तुत करें आप कैप्चर एरर को मैन्युअल रूप से कॉल कर सकते हैं:

function Error({ statusCode, message, err }) {

const serverSide = typeof window === 'undefined';

  // only run this on server side as APM only works on server
  if (serverSide) {
    // my apm instance (imports elastic-apm-node and returns  captureError)
    const { captureError } = require('../src/apm'); 

    if (err) {
      captureError(err);
    } else {
      captureError(`Message: ${message}, Status Code: ${statusCode}`);
    }
  }

}

सभी को प्रणाम! हमने एक्सप्रेस सर्वर को जोड़े बिना नेक्स्ट.जेएस में एक्सप्रेस स्टाइल आर्किटेक्चर के लिए एक एनपीएम लाइब्रेरी लॉन्च की है। यह आपके सर्वर त्रुटि प्रबंधन चुनौतियों के लिए सहायक हो सकता है! यदि आप रुचि रखते हैं तो इसे देखें। https://github.com/oslabs-beta/connext-js

किसी को भी getServerSideProps में होने वाले अपवादों को पकड़ने (और संभालने) में सफलता मिली है?

किसी को भी getServerSideProps में होने वाले अपवादों को पकड़ने (और संभालने) में सफलता मिली है?

यह स्पष्ट नहीं है, आपको लगता है कि एक ढांचा क्लाइंट और सर्वर दोनों त्रुटियों को लॉग करने का एक मुहावरेदार तरीका प्रदान करेगा ‍♂️

किसी को भी getServerSideProps में होने वाले अपवादों को पकड़ने (और संभालने) में सफलता मिली है?

@stephankaag

हाँ, ऐसा कुछ मेरे लिए काम करता है:

क्रैश रिपोर्टिंग को संभालने के लिए पहले एक मिडलवेयर बनाएं। मैंने Sentry को CrashReporter वर्ग के अंदर लपेट लिया है क्योंकि केवल Sentry लौटने से काम नहीं चलेगा (यानी req.getCrashReporter = () => Sentry )।

// crash-reporter.js

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

class CrashReporter {
  constructor(){
    Sentry.init({ dsn: process.env.SENTRY_DSN });
  }
  captureException(ex){
    return Sentry.captureException(ex);
  }
}

function crashReporterMiddleware(req, res, next) {
  req.getCrashReporter = () => new CrashReporter();
  next();
}

module.exports = crashReporterMiddleware;

अगला, निश्चित रूप से, Next.js अनुरोध हैंडलर सेट होने से पहले अपने ऐप में मिडलवेयर लोड करें:

// server.js

const crashReporterMiddleware = require("./middleware/crash-reporter")

...

app.use(crashReporterMiddleware);

...

setHandler((req, res) => {
  return handle(req, res);
});

फिर आप जहां कहीं भी कॉल करें getServerSideProps :

// _error.js

export async function getServerSideProps({req, res, err}) {
  const statusCode = res ? res.statusCode : err ? err.statusCode : 404;
  const crashReporter = req.getCrashReporter();
  const eventId = crashReporter.captureException(err);
  req.session.eventId = eventId;
  return {
    props: { statusCode, eventId }
  }
}