yarn add relay-sentryimport { 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 {}
}
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 🕺
Options
| Option | Description | Default |
|---|---|---|
filterEvents?: (logEvent: LogEvent) => boolean |
Use to filter log events from creating breadcrumbs | undefined |
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.
MIT © Marais Rossouw