Is it okay than sentry/electron transport drops all info from response and sentry/core base-transport tries to check it?

[origin-yaropolk]

Is there an existing issue for this?

• I have checked for existing issues https://github.com/getsentry/sentry-javascript/issues
• I have reviewed the documentation https://docs.sentry.io/
• I am using the latest SDK release https://github.com/getsentry/sentry-javascript/releases

How do you use Sentry?

Sentry Saas (sentry.io)

Electron SDK Version

5.1.0

Electron Version

30.1.2

What platform are you using?

Windows

Link to Sentry event

No response

Steps to Reproduce

Expected Result

I want full info in response.

Actual Result

I see some dissonance in the fact that, on the one hand, the sentry removes information from the response, and on the other hand, it tries to immediately check it.

Also, in this case, events like 'afterSendEvent' doesn't make sense with empty response.

[lforst]

From what I can tell the electron SDK will return the headers which is everything the SDK needs. The fact that the status code isn't returned doesn't matter except for logging. I'll let @timfish confirm though!

[timfish]

I've tried withstatusCode included and the tests all pass so maybe the question is why not include this if it impacts afterSendEvent?

[lforst]

Just to be conscious around API surface I think. The more we expose the more can break. And this doesn't seem necessary 🤔 @origin-yaropolk what is your use case?

[timfish]

Oh ok, if we don't return the statusCode, the only thing this appears to impact outside of afterSendEvent is outputting this warning:

          // We don't want to throw on NOK responses, but we want to at least log them
          if (response.statusCode !== undefined && (response.statusCode < 200 || response.statusCode >= 300)) {
            DEBUG_BUILD && logger.warn(`Sentry responded with status code ${response.statusCode} to sent event.`);
          }

[timfish]

I've opened a PR to pass through the status code because it's low risk and it seems like this was expected at some point.

It's worth noting that the Electron SDK's default transport has an offline cache. This means that if the event cannot be sent, it is saved to retry later and a default status code of 200 is returned. For this reason, the status code returned by the transport is not a clear indicator of the sending status!

[origin-yaropolk]

And this doesn't seem necessary 🤔 @origin-yaropolk what is your use case?

I don’t have a specific use case.
I came across this inconsistency when I was looking for a way to get rid of event spam when the quota is over.

[origin-yaropolk]

I’am sure that old sdk version below 3.0.0 had another behaviour.