Thomas B

> Nothing is going to be bricked. It's unclear to me why this may not brick machines considering https://github.com/Foxboron/sbctl/wiki/FAQ#option-rom

Soft-bricking seems like a very appropriate term. "You can still very much solve the issue": if the laptop is secure-boot enabled, not booting and doesn't have a display nor a...

Thank you for your answer! 🙂 So it looks like my understanding was correct: to generate target paths, I'm tied by either the builtins (which I can't customize) or the...

Hey! Thanks for letting me know! That's indeed very interesting! I may give this another look in the coming weeks. 👍️

> As you mention Futures and their lifecycle, you must use the SentryFuture wrapper as well, using .bind_hub(), otherwise concurrent futures will get a messed up Scope. Unfortunately, its a...

Aha digging further into this it seems that it already attaches to the top scope of the main thread, so the issue may be that the sentry initialization leaves without...

> so the issue may be that the sentry initialization leaves without actually `push`ing a scope level That actually wouldn't work: any `Hub::new_from_top(Hub::current())` on the main thead itself wouldn't attach...

Ok so I'm trying to understand how it's supposed to work but there's something I don't understand: `Hub::push_scope()` ends up calling this function, but: https://github.com/getsentry/sentry-rust/blob/8cc4848f115152af6f2ad66d7aeb17bd3bbe38fd/sentry-core/src/scope/real.rs#L86-L89 actually pushes a `clone` of...

Ok so my understanding is that there's no way to prevent the `Hub` to attach to the current scope of the main thread. It looks like the "main Hub" shouldn't...

What's going wrong is in the scenario where I do: 1. Init sentry on main thread 2. Spawn a sub-thread 3. Keep doing work on main thread 4. sub-thread calls...