Introduce Multiplexing Transport
See original GitHub issueProblem Statement
Usage of multiple hubs/clients has been a long standing issue within the SDK. https://github.com/getsentry/sentry-javascript/issues?q=is%3Aopen+is%3Aissue+label%3A"Feature%3A+Multiple+hubs%2Fclients"
A big use case for using multi-hub is to send Sentry event’s to different projects. By introducing an optional transport multiplexer, we can allow users to route envelopes to different DSNs (or the same envelope to multiple DSNs).
This means users can route events to different Sentry projects based on any characteristics of an event - like tags, stacktrace or contexts
Solution Brainstorm
Most transports constructors right now (makeFetchTransport
, makeXHRTransport
) are a function that takes some transport options and returns a transport.
transport: (options: TransportOptions) => Transport
We could then make a wrapper class typed like so:
type DsnToMatcher = {
// TODO: Adjust matcher function type based on UX needs
[dsn: string]: (type: string, envelopeItemBody: unknown, envelopeItem: BaseEnvelopeItem) => boolean;
}
type TransportCreator = (options: TransportOptions) => Transport
type TransportMultiplexer = (opts: DsnToMatcher, wrappedTransport: TransportCreator) => TransportCreator;
It’s just a wrapper func, so it would be used like so:
Sentry.init({
dsn: ...,
transport: multiplexTransport(makeFetchTransport),
});
There are a couple open questions here:
- Do we make this errors/transaction only? What do we do about sessions, attachments and other envelope items
- How do we easily design the API so that it can we can route to different DSNs and send envelopes to multiple DSNs at the same time.
- Do we expose entire envelope items? Or just the body.
There is an argument that this needs can just be a code snippet in docs, instead of exporting something, but it would be nice to have this functionality out of the box to address some of the MFE concerns.
Issue Analytics
- State:
- Created a year ago
- Comments:6 (6 by maintainers)
Top GitHub Comments
I think this is a good idea! Our current workaround (using
beforeSend
to do the routing) only works for errors, and it would be nice to have an easy way for folks to make this work.A few thoughts:
I think it only makes sense if we do it for everything, otherwise you still have one project’s data getting stored in another project. (This does beg the question of what to do when there are multiple items in an envelope, of course, but I think we can figure that out.)
The matcher that you’re envisioning - is the idea that for each DSN, we’d run the corresponding matcher, and if it returned true, we’d send to that DSN, and if it returned false, we wouldn’t?
It feels much more intuitive to me (and is probably less code for users) to have people write one function (rather than one per DSN) and have it return the DSNs which should receive the event/session/etc. (We can figure out the easiest way to handle default behavior, if users want that for most stuff by not everything.)
I def think just the body. There’s nothing in the headers people need, IMHO, and besides, envelopes are an implementation detail that I’d rather not tie us to with public API.
I like your idea to use
tags
and let the user do whatever they want