suggestion: if the plan is to eventually migrate to the in-built browserWebsocketStream (and from what I can see, it is onsome sort ofstandards track), it might be worth treating this like vendored code that shouldn't be modified and doing theseResultAsync patches where this is being used in the signal client code.

I can think of pros and cons to both approaches though so I'd be curious to hear your rationale if there is a reason why doing this would be overly burdensome.

Fair point. Was thinking about this too. I have currently less confidence into adapting the standard proposal any time soon. Given that, I think starting with the error propagation at the lowest level sounded like the right choice to me

suggestion(non-blocking): When I was first trying to parse through this I saw you swapped allthis ->self and it took me a second to figure out exactly whereself was being assigned and why you had done this. It looks like (from what I can tell) it's due to the generator function creating a new explicitthis scope.

I wanted to propose another option instead - something likeasync function* () {}.bind(this). There's some discussion here on the pros/cons:supermacro/neverthrow#632. At least as somebody coming into reading this code for the first time, I think it would help but it's minor and something I don't have a strong opinion on.

Generally 50:50 on both, but reading through the issue you linked it mentions two steps being necessary for typescript today to properly bind it, i.e.:return safeTry(function* (this: CurrentClass) {}).bind(this) which would sway me to leave it as is.

nitpick: I think this should beResultAsync instead and the returns from this function updated to beerrAsync?

UPDATE: reading a little further, this might actually be intended. I'm still leaving this comment though because I think it's relevant to a future comment.

question: Interesting - in mylast comment I had assumed thatPromise<Result<T, E>> was a mistake, but this line implies this is very much intentional. Is this a pattern because of async functions always returning promises, ie, the same type of topic asthis issue?

Just thinking out loud but I wonder if handling this difference at this level of abstraction is the right place to do it (naively as somebody who hasn't really dug too much intoneverthrow in depth yet, this semantic difference is surprising), or if it would be better to write a utility function which can convert anyPromise<Result<T, E>> to aResultAsync<T, E>.

I think I'd need to play around with it a bit on my own to develop a stronger opinion so feel free to keep it how it is for now and we can discuss it in the future once I've been able to dig in further.

yeah, it's on purpose but mostly as an intermediate step until we have ported all async internals to the result type.

The helper function is a nice idea, we'd then have to have it include a genericError though as thePromise could still through and would have to be unwrapped safely.

Is this a pattern because of async functions always returning promises, ie, the same type of topic assupermacro/neverthrow#42?

yes, this was the reason and for the helpers I thought having a helper type to accept both would be nice

suggestion(non-blocking): another instance ofhttps://github.com/livekit/client-sdk-js/pull/1747/files#r2546082926 - consider maybe also using.bind(this) here.