The documentation says that latest on-premise version of Sentry (10.0) does not provide server-side support for events sent by sentry-native and that full support for sentry-native will be made available to all on-premise customers with the next release. How soon is the next on-premise release of Sentry planned to be delivered?
Hi @moscopole! This sounds like some outdated documentation that we need to fix 
Can you link me to it so it can be addressed?
[https://docs.sentry.io/platforms/native/](https://docs.sentry.io/platforms/native/)Link:
Ah, my bad. This is indeed correct, I thought this was something else.
This feature/SDK requires Relay which we are working on integrating into the on-premise setup. Once that’s done you can try it out
I’m a little puzzled by this. We are currently using sentry-native and it is sending events through to our onpremise instance (running 10.1.0.dev 055f8552), and it all seems to be working fine – we receive events, with call stacks and symbols. What am I missing?
@mcdurdin a subset of sentry-native’s v0.2.x features on some platforms does actually work. The good news is that it will continue to work after we wrapped up all the changes.
Particularly, this has to do with how Crashpad support is implemented. The exact condition is: If you’re running on macOS or Windows and you use the Crashpad backend, then crashes only will come through. This means:
- Linux and Android do not work
- Any other backend than Crashpad does not work
- Custom events (e.g.
sentry_capture_event) do not work, even with the Crashpad backend on macOS and Windows.
On the bottom line, as long as it works for you, you’re all set
2 Likes
That’s curious … 
because we are using sentry_capture_event quite successfully – both with the Crashpad backend enabled and with it disabled. We’ve got minidumps coming through with Crashpad. We have custom exception reports with call stacks and full symbolication, breadcrumbs and informational events.
Not complaining… it’s great! Looking forward to seeing formal support in the On Premise setup.
FWIW, we went On Premise because we want to keep a record of crashes a lot longer than 90 days. I think the usage model for native APIs would suggest that a 90 day history for events is far too small as native apps tend to have long life-cycles; we want to keep crash reports forever.
At time that older events are purged, it would be great to keep just a representative sample of events older than 90 days for each issue, plus aggregated statistics, so we can still deal with rarely reported exceptions, and see a pattern over time for a given issue. But I don’t think Sentry can do that? For us, this would provide a good balance between history and storage and would probably mean we’d consider moving to the hosted solution.
Just to clarify here.
Regular capture_event was still using the regular store endpoint. Hard crashes using the inproc or breakpad backends, and sessions (starting with the next patch release) are sent to the new envelope endpoint which requires relay.
I want to simplify the implementation to only send to the envelope endpoint. I think I rather do that as a breaking release, and clean up the transport interface along with it.
2 Likes