Conversation
|
I like it! IMHO it is not that easy to handle envelopes (since replay), so it's nice if we can provide this to users instead of asking everybody to re-implement this. |
|
The envelope parsing utils are also all in |
d7e4174 to
3d06abc
Compare
3d06abc to
96429cb
Compare
|
@AbhiPrasad & @timfish should we revive and merge this? I think it would be nice still! |
|
A few weeks ago Abhi said to wait on this for now because we have other general tunnelling improvements planned. |
|
Yup. After I get the initial logs stuff merged in for the JS SDK, I think we can take a look at this in detail. |
|
@timfish @AbhiPrasad any updates on this? |
|
This pull request has gone three weeks without activity. In another week, I will close it. But! If you comment or otherwise update it, I will reset the clock, and if you apply the label |
|
Closing in favour of #18892 |
Closes #13453 and gives a simpler path for #10309 and adding tunnel support to other frameworks.
The current tunnel troubleshooting docs suggest this code but it doesn't work with binary envelopes so breaks with compressed replay envelopes and attachments.
Rather than get users to parse their own envelopes for this info, this PR adds a
handleTunnelEnvelopefunction to@sentry/corewhich handles all the logic for forwarding envelopes.If your client DSN is the same as your server DSN, the above example code becomes:
If you want to forward envelopes for other DSNs, you can just pass an array as
dsnAllowListin the options. Not sure about this naming. IsallowedDsnsbetter?We can further wrap the
handleTunnelEnvelopefunction and expose more complete examples for each framework. For example we could expose a helper which takes aRequestand returns aResponseor export an API route ready to use.