Trying to understand release health for services (long running applications)

[JanFellner]

Using sentry native i noticed that release health is sent when the application is shutting down (calling sentry_close)
While this concept very likely works smoothly for short running applications i see a problem with long running applications.

What is the idea for seeing version adoption if i have services that run for weeks?

I played around with capturing events but that is instantly seen as issue...

auto event = sentry_value_new_message_event(SENTRY_LEVEL_INFO, "custom", "started");
sentry_capture_event(event);

How to get release health data also when an application is launched?

[supervacuus]

By default, the session life-cycle is bound to the SDK life-cycle (typically bound to the application life-cycle). However, you can create arbitrary session bounds by turning off auto-session-tracking (sentry_options_set_auto_session_tracking()) and starting and ending sessions manually (sentry_start_session() and sentry_end_session()).

We currently only support one global session, so sessions per request in a server application are impossible. However, you could restart (sentry_start_session() ends the previous session first) the session in regular intervals and keep it connected via a consistent user ID (for a particular deployment environment).

But, to be clear: even if your application runs for weeks at a time and the application life-cycle binds the sessions, any event being sent within session bounds would result in an updated session and thus a health signal. So, you don't have to wait for sentry_close() to receive updates, but some API interaction would be necessary.

[JanFellner]

The last sentence now opens a new window :).

What could i send that is not interpreted as issue. I am exactly searching that call that just announces, there is something going on but this is not an issue i am now sending. ChatGPT fabulates about transactions i could do but all my tries in the end led to issues i also get informed about via mail...

(and huge thanks for providing such really details answeres, also the other one :))

[supervacuus]

(and huge thanks for providing such really details answeres, also the other one :))

You're very welcome. Please be aware that this only happens when auto_session_tracking is enabled or you explicitly started a session before capturing anything.

What could i send that is not interpreted as issue.

Again, you could restart a session right after you create one or initialize the SDK with auto_session_tracking; this will immediately capture the session (resulting in no issue) and register your release. The only downside is counting more sessions than actual application life-cycles, but I don't know whether this would be problematic in your scenario.

[JanFellner]

I´m fixing it, kind of dirty, but that is an approach i can live with.
If i have a "long running" application like a system service i am storing the version of my application inside the .sentry folder.
In case that version changes due to an update i restart the session right at the start to see version adoption.
This leads to the fact that when a new version comes out i see more session but i will have at least some adoption in the sentry dashboard.

In the end that would be something which would be interesting to see in sentry itself (exactly with that pattern. If the version changes announce that to the server side)

[JanFellner]

Closing it, as sentry itself does not fullfill the need, but i have a workaround :)