rfc(feature): SDK Fail-Safe Mode

[philipphofmann]

This RFC aims to minimize the damage of a crashing SDK in production. It’s better to have no data than crashes and no data.

Rendered RFC

[armcknight]

Exciting to see this being discussed! The scenario analysis is looking good 👍🏻 It might be worth moving options 2 and 3 to a separate RFC as "remote configuration" as that's a different can of worms (there are several docs in Notion about this as a potential feature set) and keep 1 and 4 here.

[philipphofmann]

It might be worth moving options 2 and 3 to a separate RFC as "remote configuration" as that's a different can of worms (there are several docs in Notion about this as a potential feature set) and keep 1 and 4 here.

Thanks for the input. I still want to keep them in this RFC as it helps us understand how to tackle all different scenarios. If we decide we want to move forward with these, we need to open another RFC to clarify the implementation details because, as you said, that's a different can of worms.

[cleptric]

Can't this be a regular event envelope with a special context?

[philipphofmann]

Can't this be a regular event envelope with a special context?

Yes, I actually like that more than an extra envelope item. A simple plain event with some context or something should be enough. Then users would see it in Sentry, and we can filter in the SDK crash detection for it and even create alerts. Thanks for the suggestion @cleptric, I added this in 7afaf13.

[romtsn]

Can't this be a regular event envelope with a special context?

Yes, I actually like that more than an extra envelope item. A simple plain event with some context or something should be enough. Then users would see it in Sentry, and we can filter in the SDK crash detection for it and even create alerts. Thanks for the suggestion @cleptric, I added this in 7afaf13.

The incentive was to not go through our envelope serialization pipeline at all. IIRC that was the problem that triggered this initiative in the first place, right? If we have a bug in the envelope serilization logic this will do no good.

[cleptric]

@romtsn adding a new event type to our ingestion pipeline to by-pass certain logic in an SDK feels a bit overkill, imo. You can still by-pass it in the SDK and create a normal event (error) envelope manually.

[philipphofmann]

@romtsn and @cleptric I added this to the option in 0664795

The event envelope doesn't go through the scope/hub or client. Instead, the payload for the event envelope is hard-coded, and the SDK directly sends the HTTP payload to Sentry.

Is it OK now @romtsn?

[romtsn]

@romtsn and @cleptric I added this to the option in 0664795

The event envelope doesn't go through the scope/hub or client. Instead, the payload for the event envelope is hard-coded, and the SDK directly sends the HTTP payload to Sentry.

Is it OK now @romtsn?

yes, thank you!

[philprime]

Left one comment, other than that seems fine to me

[JoshuaMoelans]

small nit on in-doc links, but LGTM content-wise!