#Rust SDK WASM Support

44 messages · Page 1 of 1 (latest)

pliant merlin
#

We want to use Sentry in a WASM environment (more specifically, the wasm32-wasip1 target). The Rust SDK almost works perfectly, except for the use of threads in SessionFlusher. I have created a fork for now to work around this, by setting the worker field of the flusher to None if on a WASM target. The diff is here: https://github.com/getsentry/sentry-rust/compare/master...pepperoni505:sentry-rust:master

Ultimately, I want to contribute to the upstream repo but I don't think my approach is a good one. From my understanding, the flusher is not "essential". Is this correct? Depending on the answer, would the flusher perhaps be better gated behind a flush feature given that some WASM targets do have threading (e.g. https://doc.rust-lang.org/rustc/platform-support/wasm32-wasip1-threads.html)

GitHub
Comparing getsentry:master...pepperoni505:master · getsentry/sentry...

Official Sentry SDK for Rust. Contribute to getsentry/sentry-rust development by creating an account on GitHub.

signal beacon
#

Thanks for your work here!!
This flusher is only used for the release health features of Sentry, so this means that we would give up those features by disabling the flusher.
So, at this point, we might as well make it a feature flag that toggles release health features directly (enabled by default).
Ideally though, I would prefer if we find a workaround to make these features work without the usage of threads.
Also, how did you deal with the transport? As far as I can tell, all transports use a separate thread to send envelopes

pliant merlin
#

Ahh ok. How often would a release health feature envelope be queued to send? Couldn't you just send them when one is ready? (I don't know what that is so keep that in mind here)

We had to write our own transport - we are running in a very interesting (questionable) WASM environment in Microsoft Flight Simulator (https://docs.flightsimulator.com/html/Programming_Tools/WASM/WebAssembly.htm) and they expose a network API there

signal beacon
#

It depends on your application, in general one of those envelopes is sent every time a Session is created.
So for example if you're running a web server, this means on every request/response cycle. But then, if you're running a web server, you will most likely be using threading, so you won't need to disabled the flusher.

#

That's an interesting usecase you got there! 😄
Unfortunately, I don't think your change will be enough for the SDK to support WASM in general (other targets), there's been many issues with it that users reported here: https://github.com/getsentry/sentry-rust/issues/226

#

However, if it helps you and possibly other people, I think it makes sense to gate the whole session/release health behind a feature flag (enabled by default) as we do with other features

pliant merlin
#

Ahhh ok, that makes sense. Is that a PR you would want me to create or are you able to tackle that?

signal beacon
#

Would be great if you can PR it, otherwise I'll create an issue for it and it's going to end up in the backlog 🙂

pliant merlin
#

Would you mind creating an issue outlining what I have to do (or is session/release health code nicely separated from the rest?) and I'll open one

signal beacon
pliant merlin
#

Thanks! I can't assign myself but I will add a comment that I will be tackling it

pliant merlin
#

@signal beacon I'm working on this now, should I gate the session_mode and auto_session_tracking fields behind the feature flag or should it always be available? My thinking is it's pointless with the feature disabled so would just lead to possible confusion

pliant merlin
#

(not gating those fields currently)

signal beacon
#

Thanks. Yeah I agree!

pliant merlin
pliant merlin
#

on the topic of the WASM support, is there a way to attach a custom stacktrace object? we can't use backtrace since it just doesn't work on the platform so we rolled our own (scuffed, but working) version

signal beacon
signal beacon
pliant merlin
#

Essentially looks like

use stacktrace::trace;

#[trace]
fn main() {
    std::panic::set_hook(Box::new(|_| {
        stacktrace::print_trace();
    }));
    foo();
}

#[trace]
fn foo() {
    bar();
}

#[trace]
fn bar() {
    let a = 1;
    let b = 2;
    let _ = a + b;
    panic!("error");
}
signal beacon
#

😄

#

It will not be that nice but you can send it to Sentry by attaching it as a string to the scope
I guess you are already doing that?

pliant merlin
#

Yeah that's probably what we will end up doing, to make matters worse the networking API in our environment drops any outgoing requests if the WASM module crashes, so on panic it won't even properly POST. Our workaround is to write to disk sychronously with an error log and on startup check if it's present, then report it 😭

#

Really not a fan of it, but it's sort of our only option here

signal beacon
pliant merlin
#

Ahhh interesting - maybe i can take a look at a possible “official” implementation then

pliant merlin
#

I have tried looking at the Java SDK implementation to copy the design but I am very thrown off by the verbose classes 😆

#

I'm thinking add cache_dir_path to ClientOptions, and a new integration for the offline store. What additional options should I have?

pliant merlin
pliant merlin
pliant merlin
#

also does it make sense to be an Integration or builtin to the core lib

signal beacon
signal beacon
# pliant merlin can i add an option to not even try to send the envelopes on panics? it would st...

I'm not sure, I would have to take a look at how to implement it, it doesn't look super straight forward
e.g. there's also this which is related https://github.com/getsentry/sentry-rust/issues/482

GitHub
Transport `send_envelope` should return a `Result` · Issue #482 · ...

I would like to create an offline transport that queues envelopes on disk if no connection is available. The only way to currently do this is to copy one of the existing transports and add the offl...

pliant merlin
# signal beacon I'm not sure, I would have to take a look at how to implement it, it doesn't loo...

Yeah, that was my first step here. I've been looking at the code and I'm not really sure what the best approach is. The simplest IMO is just to change it to report result and then for all usages of Transport::send_envelope in the lib just gets wrapped around a check if the offline store is enabled and then just save it there. But I'm not really familiar with the coding practices of the repo and further abstractions may be better

#

It also depends on how it's structured in your other libs I suppose, as there are many many ways to go about it but consistency would be nice

signal beacon
#

Yep. Tbh I've also just recently started working on the repo. So this is something we will def tackle in the future but probably not now 😄

pliant merlin
#

Ah ok, no worries then! We will roll our own solution in the meantime

pliant merlin
#

@signal beacon Are the checks failing because of the unused import? Or am I reading this wrong?

image.png
signal beacon
#

Yeah looks like it, if release-health is turned off then SessionStatus will be unused

signal beacon
pliant merlin
pliant merlin
#

@signal beacon Do you have any rough idea on when this might be merged? No rush, just seeing if I should transfer my fork to my org before we deploy to prod if it is on "hold" for a bit

signal beacon
#

Hey I just wanted to remove the lock on session_flusher as Arpad suggested before merging it, I'll do it probably today or tomorrow.
Then I'm targeting to do a release which will include it latest on monday!