You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When returning a JSON-RPC error response, I suspect it would be a good play to block transmission of any exotic types. This is primarily because exotic types tend to pin resources till the receiving side fulfills some contract (e.g. disposing of the received proxy), and in the exception case this is more likely to be missed.
While blocking such a thing would be a breaking change, it's unlikely anyone depends on it right now.
Consider that exceptions might be sent as arguments or return values (rather than thrown), and in such cases we may want to continue allowing exotic types.
The text was updated successfully, but these errors were encountered:
CC: @matteo-prosperi. We should think about this with regard to generally marshalable types, but as I think this is a pre-existing problem, I figured I'd file an issue to resolve later rather than hold up your current PR.
When returning a JSON-RPC error response, I suspect it would be a good play to block transmission of any exotic types. This is primarily because exotic types tend to pin resources till the receiving side fulfills some contract (e.g. disposing of the received proxy), and in the exception case this is more likely to be missed.
While blocking such a thing would be a breaking change, it's unlikely anyone depends on it right now.
Consider that exceptions might be sent as arguments or return values (rather than thrown), and in such cases we may want to continue allowing exotic types.
The text was updated successfully, but these errors were encountered: