Sentry Envelopes/Tunnel
I have a PHP project and some JS on the FE, the PHP Sentry stuff works great but I've run into issues trying to get the JS side working with buggregator.
Doing the using a tunnel results in Client error: POST http://127.0.0.1:8000/api/1/envelope/resulted in a404 Not Found response and trying to use it directly with the tunnel results in server_name is undefined on https://github.com/buggregator/server/blob/master/app/modules/Sentry/Application/Mapper/EventTypeMapper.php#L28
https://develop.sentry.dev/sdk/envelopes/ https://docs.sentry.io/platforms/javascript/troubleshooting/
Both of these work on production sentry
Hey there! It looks like your JavaScript side is having a bit of trouble connecting with Buggregator due to some missing or incorrect settings. Here's how you can try to fix it:
- Set the Environment Variable: Make sure you have the correct environment variable set up in your Buggregator Docker configuration. This tells your JavaScript where to send error reports.
You can set it like this in your environment file (.env):
SENTRY_JS_DSN_HOST=http://sentry@server_name:8000
Replace server_name with the actual name of your server. This should match the setup you have for your PHP project if that's working well.
- Check the Configuration Guide: Double-check the settings by looking at the configuration guide for Buggregator. You might find some extra steps or requirements that you missed. Here’s a helpful link: https://docs.buggregator.dev/config/sentry.html#configuration-3
Thanks for the reply, I am trying to setup envelope since this is what well end up getting used on release.
The JS has this but im not sure this matters since it sends the request to the tunnel and the PHP backend is what is actually sending the request.
Sentry.init({
dsn: import.meta.env.VITE_SENTRY_ALERT_DSN,
tunnel: "/sentry",
});
the PHP code is using guzzle and looks like so
try {
$response = (new Client())->post("$protocol://$host/api/$id/envelope/", [
'headers' => [
'Content-Type' => 'application/x-sentry-envelope',
],
'body' => $data
]);
} catch (Throwable $e) {
$this->response->setStatusCode(500, 'Failed to send to Sentry');
return $this->response;
}
This ends up throwing this
Client error:
POST http://127.0.0.1:8000/api/1/envelope/resulted in a404 Not Foundresponse`
Using the same DSN http://[email protected]:8000/1 results in successful error logs when calling it directly via the PHP sentry client which works amazing.
Sentry\init([
'dsn' => 'http://[email protected]:8000/1',
]);
Sentry\captureMessage('Test');
Setting this up to point to a real sentry DSN results in both of them working so it's only buggregator that doesn't allow envelopes to work.
@butschster So I ended up getting some more time to play around with this and the Tunnel/Envelope itself does work, my issues ended up being that it was failing trying to parse the sentry_key.
To get this to work I needed to add ?sentry_key=null well ?sentry_key=anything would work. but I'm not entirely sure why this is required. I think this has something to do with https://github.com/buggregator/server/blob/master/app/modules/Sentry/Application/SecretKeyValidator.php#L17
On production sentry this isn't required, I assumed I was passing my headers wrong so I checked how the sentry php sdk is doing it so I could ensure I was using the correct headers.
$response = (new Client())->post("$protocol://$host/api/$id/envelope/", [
'headers' => $this->getRequestHeaders($header),
'body' => $data
]);
This is trying to sending too http://[email protected]:8000/api/1/envelope/ and the headers look like
0 => "Content-Type: application/x-sentry-envelope"
1 => "X-Sentry-Auth: Sentry sentry_version=8.27.0, sentry_client=sentry.javascript.browser/8.27.0, sentry_key=sentry"
but will error out with Client error: POST http://[email protected]:8000/api/1/envelope/ resulted in a 404 Not Found response if I don't include ?sentry_key=. Changing this to "$protocol://$host/api/$id/envelope/?sentry_key=sentry" will get it to work but will break production (even with the correct key)
Again, not including ?sentry_key= works fine on production sentry so I think there is something with the way we are trying to parse it out of the request. On production sentry I didn't even need to include the X-Sentry-Auth header either.
Could they be parsing the key from the DSN url?