Documentation of possible response codes for store endpoint

SDKs
1

I have read:


And found documentation about response code 200 (containing an event id) and 429 (telling the caller to hold off).

However there are more response codes returned by the store API, like for instance:
403 Event dropped due to filter: web-crawlers

I haven’t found an exhaustive list of response codes a caller should handle.
Also, the 429 is mentioned explicitly, but in the Sentry docs, I haven’t found details on how to hold off.

Is this information available somewhere publicly in the Sentry docs or maybe in an internal (Swagger) API doc?

(oh yeah, I’m using Sentry 9.1.2)

2

We don’t make API compatibility/stability guarantees about sending more response codes and especially not about the response content of a 403. Our SDKs are coded in a way where they, in principle, can deal with any kind of response code (they just log it if it’s not a 2xx), but special-case 429 to actually stop sending events.

3

Currently we are doing exactly what you say:

  • 200 : Great, logged successfully
  • 429 : Okay, hold off temporarily
  • Other: log internally

But besides this, some non-200s are “more equal than others”, especially a 403:Forbidden:

I assume that for example using an invalid API key would also result in a 403, which is way more important than my individual request being deemed coming from a bot (which is very likely to be true in the case: the cause of our issue was in fact a bot, and I couldn’t care less about this not appearing in Sentry.)

I get that maybe keeping track of each version in the docs is a hassle (including the docs in the API would be a solution, example of built-in response codes specified in Swagger:

image
image1435×1247 37.5 KB

4

I’m actually curious how you got a 403 for web crawlers, is this on sentry.io? I’d think we return 200 for those by now

What do you want to do when you have an invalid dsn? log with higher severity or do something else entirely?

5

Nope this is using on-prem, 9.1.2

Response code: 403
Response content: {"error":"Event dropped due to filter: web-crawlers"}

We are running Sentry 9.1.2 using the rebuilt-docker image:
https://hub.docker.com/_/sentry?tab=tags > latest (one year old)

Sentry is exposed using IIS as a reverse proxy. This máy affect the response code, but currently deem this not likely.

Wouldn’t you agree that a 200 for a dropped request is surprising? I would expect:

200
=> Ok
=> Response contains reference number
=> Reference number can be found in Sentry UI

If not, and a 200-response may need to be interpreted, this may also be relevant to see in the SDK docs for developers of integrations.

6

In Sentry 10 we always send a 200 OK because the actual filtering happens asynchronously. I agree that it makes debugging harder, but a big goal was to bring store response times down for platforms that have poor async IO capabilities. We do have filtering stats in the project settings though that give you counts as to which proportion of your events has been dropped.