Skip to content
This repository has been archived by the owner on Aug 14, 2024. It is now read-only.

Finish and capture transaction/span bound to the Scope in case of a fatal crash-shutdown (eg Java Unhandled exception) #443

Open
2 of 5 tasks
marandaneto opened this issue Oct 4, 2021 · 8 comments

Comments

@marandaneto
Copy link
Contributor

marandaneto commented Oct 4, 2021

Add missing SDKs, See SDKs that support the Perf API https://docs.sentry.io/product/performance/getting-started/

@marandaneto marandaneto changed the title Finish and capture transaction/span bound to the Scope in case of a fatal crash (eg Java Unhandled exception) Finish and capture transaction/span bound to the Scope in case of a fatal crash-shutdown (eg Java Unhandled exception) Oct 4, 2021
@marandaneto
Copy link
Contributor Author

cc @rhcarvalho @AbhiPrasad @mitsuhiko in case you know which SDKs should do it as well, please edit the description so we can track it

@bruno-garcia
Copy link
Member

bruno-garcia commented Oct 20, 2021

In sentry-cocoa it would require serializing the data into the SentryCrash state so it gets dumped on a crash so not super trivial. Mainly because of the overhead it'll add since any change in the transaction would require serialization.

On SDKs that have a runtime like Dart (Not in Flutter since it doesn't crash), C#, Java it could be as simple as changing the uncaught handlers to not only capturing the exception but closing any open transaction from the scope and capturing that too before terminating the app

@krystofwoldrich
Copy link
Member

krystofwoldrich commented Oct 13, 2022

On Dart Flutter never crashes so we don't need to do anything.

On hybrid sdks we only care about the transaction running on its own layer (JS RN).

@mattjohnsonpint
Copy link
Contributor

For .NET we are addressing in getsentry/sentry-dotnet#1996

We needed to choose a transaction status for these failed transactions. Since the unhandled exception is interrupting the transaction, we went with aborted.

@marandaneto
Copy link
Contributor Author

@mattjohnsonpint awesome, can you amend the spec for this specific use case?

@marandaneto
Copy link
Contributor Author

@mattjohnsonpint awesome, can you amend the spec for this specific use case?

@mattjohnsonpint have you had the chance to work on this? Apparently, .NET and JS diverge in status, .NET uses aborted and JS uses internal_error for quite some time.

@mattjohnsonpint
Copy link
Contributor

I haven't updated the spec yet. Thanks for the reminder.

In TSC it was said that this behavior wasn't applicable for JS. I also mentioned status aborted in TSC without any objection, so I think we should stick with that unless there's a concern?

I'm not sure that it really matters much, as long as it's not status ok.

@marandaneto
Copy link
Contributor Author

In TSC it was said that this behavior wasn't applicable for JS

JS sets the status, but the transaction keeps running because the process (browser) never dies, that's why it's not applicable to JS, so aborted wouldn't make sense, I believe the spec should include both behaviors.

  • If the process is going to die, set status to aborted and finish the transaction.
  • If the process/browser keeps running, set the status to internal_error and let the transaction finish itself.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
Status: Backlog
Development

No branches or pull requests

6 participants