Tracking for errors thrown server-side

[TryingToImprove]

I needed to track errors thrown from Remix server-side. From my investigation into this, it seem like the createRequestHandler handles the errors thrown - it makes sense it needs to do it's magic for ErrorBoundaries.

However it prevented me from using a global express middleware which would handle errors thrown.

I got something working using patch-package like below:

diff --git a/node_modules/@remix-run/server-runtime/data.js b/node_modules/@remix-run/server-runtime/data.js
index 83ccdb1..77790c4 100644
--- a/node_modules/@remix-run/server-runtime/data.js
+++ b/node_modules/@remix-run/server-runtime/data.js
@@ -39,6 +39,10 @@ async function callRouteAction({
       params: match.params
     });
   } catch (error) {
+    if (typeof globalThis.errorTracking === 'function') {
+      await globalThis.errorTracking(error)
+    }
+    
     if (!responses.isResponse(error)) {
       throw error;
     }
@@ -76,6 +80,10 @@ async function callRouteLoader({
       params: match.params
     });
   } catch (error) {
+    if (typeof globalThis.errorTracking === 'function') {
+      await globalThis.errorTracking(error)
+    }
+    
     if (!responses.isResponse(error)) {
       throw error;
     }
diff --git a/node_modules/@remix-run/server-runtime/server.js b/node_modules/@remix-run/server-runtime/server.js
index 6ecede8..b4f0581 100644
--- a/node_modules/@remix-run/server-runtime/server.js
+++ b/node_modules/@remix-run/server-runtime/server.js
@@ -160,6 +160,10 @@ async function handleDataRequest({
       console.error(error);
     }
 
+    if (typeof globalThis.errorTracking === 'function') {
+      await globalThis.errorTracking(error)
+    }
+
     if (serverMode === mode.ServerMode.Development) {
       return errorBoundaryError(error, 500);
     }
@@ -427,6 +431,9 @@ async function renderDocumentRequest({
         message += `\n\n${String(error)}`;
       } // Good grief folks, get your act together 😂!
 
+      if (typeof globalThis.errorTracking === 'function') {
+        await globalThis.errorTracking(error)
+      }
   
       return new Response(message, {
         status: 500,
@@ -471,6 +478,9 @@ async function handleResourceRequest({
       message += `\n\n${String(error)}`;
     } // Good grief folks, get your act together 😂!
 
+    if (typeof globalThis.errorTracking === 'function') {
+      await globalThis.errorTracking(error)
+    }
 
     return new Response(message, {
       status: 500,

entry.server.tsx

// @ts-ignore Custom code to handle error tracking server-side for remix..
globalThis.errorTracking = async (error) => {
  trackError(error)
};

---

It would be nice if there were a way to hook into the error functionality in order to send errors to ex. sentry.io.

[TryingToImprove]

Investigated a little more; See this thread on discord: https://discord.com/channels/770287896669978684/970608233880363049

However I think I might be able to do something like https://github.com/jacob-ebey/remix-sentry/tree/7ec8c84689b1cadb2752e741c152d0981f5d45f0/server but I need to test that I get all the errors I remix can throw.

[dmarkow]

I tried that remix-sentry example code tonight. It works if your loaders/actions specifically throw an error. However, it doesn't cover anything Remix does between running your loader/action and passing the response back to the client. This means that some errors, such as "you defined a loader but didn't return anything" don't get caught. I tried catching on the client side in the error boundary, but in production mode, Remix just sends back a vague "unexpected server error" message instead of the details.

I ended up doing something similar to your patch-package solution instead which seems to be working fine.

[jaschaio]

I need this as well. Patch package seems ugly, especially as I feel that I am already patching around so many other limitations of remix.

[jaschaio]

Btw. probably a duplicate of #2190

[kiliman]

Yes, patch-package isn't optimal, but:

1. it unblocks you so you can continue building your app
2. it gives Remix team a concrete use case to come up with a good API

Having working code out in the wild is a much better way to figure out what the API needs to handle. Remember, anything added to Remix will have be supported by the team forever.