We have a .Net Core application comprising of a Desktop client, and 3 Windows Services. 2 of those services do not have access to the Internet, but we want to be able to write sentry reports (exceptions, other events etc) to disk, or communicate them in some way to the 3rd service (which has internet access) to post them to Sentry on their behalf.
Is there a common pattern for doing this?
The Sentry .NET SDK 3.0.0 (which is still in preview) supports offline caching. It expects to eventually get back online to sent the events over the network though.
How do you plan to take the cached events out of the offline services?
The 3rd service, the one that reads the cache, has access to the internet. So the 2 restricted services would simply be using the cache to write their events, and the main service would pick them up immediately and push them to Sentry over the Internet.
Alternatively, if it is possible to serialise an event, that would mean there was no need to use a cache as they could send the events using an IPC channel to the main service.
The event is serialized in order to be sent over the network or written to disk (what we’ve been calling 'writing to cache").
You suggested IPC so the services are in the same machine but only 1 of them has Internet connection?
Can I ask why is the setup this way? Do the offline services have connection through the internal network at least? If so, you could run Relay on one of your machines and give only that machine access to the Internet.
It’s a security/privacy focused application. The service with access to the Internet runs with lower permissions. The two services that we don’t want to access the Internet both run with “Local System” permissions, so we restrict access to and from these services.
Do you have any handy code snippets showing caching and/or serialising? It’s a new application that we haven’t released yet, and it probably makes sense, given our requirements to start coding against v3 of the SDK.
Also, do you have any rough estimates on release timeframe for v3? Q1 next year?
Sentry .NET 3.0.0 goes GA in Q1 for sure. We’re adding performance to it too before dropping the preview label.
The code that deals with caching the envelopes is very much internal:
Letting the Local System services have access to an internal service (Sentry Relay), and only this service, is likely the simplest approach instead of trying to have one service connect to the other two file systems to pull crash reports from it.
Thanks for the information 
I don’t think a relay works for us since this is a consumer application for Joe Public. Can 3 services share the same caching directory, with 2 writing to it, and 1 reading from it?
The transport needs to keep a max number of files (so you don’t fill up the disk in worst case) and also it deletes the oldest files first while keeping the order for submission.
It’s optimized for a single app instance, it requires exclusive access to the directory.
You could implement your own transport based on that one though. You can pass your own implementation via SentryOptions when you init the SDK.
Basically you could just write the file to a path, without trying to send anything over the network. And have another process that just reads from that folder and calls Sentry.CaptureEnvelope… Then you need to make sure you’re not filling up the drive (have a max number of files, etc)
Sounds perfect, thanks.