Relay log function that enriches Sentry with Relay life cycles and GraphQL data


Keywords
relay, graphql, sentry, error
License
MIT
Install
npm install relay-sentry@0.1.1

Documentation

relay-sentry

Relay log function that enriches Sentry with Relay lifecycle's and GraphQL data


downloads size size

⚙️ Install

yarn add relay-sentry

🧱 Usage

import { logFunction } from 'relay-sentry';
import { Environment } from 'relay-runtime';

const environment = new Environment({
  log: logFunction(),
  network,
  store,
});

If you want to also include the GraphQL errors array to the Sentry exception context. You can throw a _ custom_ Error class that contains a property called graphqlErrors. Internally we look for that key on the error object, and send it.

Under the hood it uses @sentry/minimal so there is no discrepancy between Node/Browser runtimes.

TypeScript users, we export an interface to help:
import type { ErrorWithGraphQLErrors } from 'relay-sentry';

declare global {
  interface Error extends ErrorWithGraphQLErrors {}
}

🎢 What does it look like?

breadcrumbs

Leaves a debug/info breadcrumb trail for all intermediate life cycle events.

At this stage it doesn't filter any variables, but if there's a need for it—submit a PR 🕺

🔎 API

logFunction(options?: Options): LogFunction

Options

Option Description Default
filterEvents?: (logEvent: LogEvent) => boolean Use to filter log events from creating breadcrumbs undefined

Help

How can I log something custom?
import { logFunction } from 'relay-sentry';
import { Environment } from 'relay-runtime';

const environment = new Environment({
  log: (logEvent) => {
    logFunction(logEvent);
    // Do your logs
  },
  network,
  store,
});
The error's context looks like [ [Object] ]

When you're running Sentry.init set the normalizeDepth to something bigger, maybe 10.

My fetchFn is throwing an exception but it isn't appearing in Sentry?

relay-sentry used to also manually capture an exception thorough the captureException Sentry api. However, through user feedback and further exploration we found it best to leave that to the consumer through the use of an async-boundary or alike. This avoided the double error emission (or event) for an error that would have also been emitted by those boundaries.

License

MIT © Marais Rossouw