-
Notifications
You must be signed in to change notification settings - Fork 12
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Document rendezvous server error handling #15
Comments
Whenever the program is started with |
I did a quick code dive and found some answers too:
|
So the most important question is: "should we restrict If yes:
If no:
|
I just noticed that this has implications for our new permissions system too: what does it actually mean for the server to "error out"?
|
It makes sense to at least close on "permissions failed" I think, since those permissions are scoped the "the connection" so what else could you possibly do .. besides maybe try something else, i.e. a new permissions message, but also re-connecting doesn't seem like much of a burden there. |
I propose the following changes and clarifications to the spec:
Backwards compatibility:
What do you think? |
I'm not sure why we should mess with the So, I don't know that we need to assign any semantic significance to them; indeed, it may collide with the goal of measuring timings (because we'd delay -- slightly -- when that message gets sent if the semantics become "processed correctly" rather than "received + parsed"). Several message types already allow for "error" to be sent as a response. They also have explicit "reply" messages for success (e.g. The best way to analyze this is likely by tying it back to the state-machine(s); are there any places we can get "stuck" in the machine? Regardless of that, part of this seems to be small enough to be its own proposal: that |
I thought of this too recently, and it is indeed a viable solution if messing with
Yes, the recently added
Not sure what you mean exactly, and which machine of which implementation you are referring to, but in either case the answer is a pretty confident yes :)
The only one that I can think of is magic-wormhole/magic-wormhole-mailbox-server#19
We can also make this a separate error type, FWIW What are your thoughts of bumping the WebSockets end point version instead of bothering with backwards compatibility? I wrote down some ideas earlier today inspired by all of this that simplify a lot of other things. I still need to check how easy they would be to add to the current relay server implementation (gut feeling says it should be okay). |
At the moment, this part is heavily under-documented in the specification, only giving the following information:
* S->C error {error: str, orig:}
error
field in thewelcome
messageI suggest having a look at our reference server implementation (https:/magic-wormhole/magic-wormhole-mailbox-server) and then write down some details that are compatible with it. Open questions at the moment:
error
message? What error strings are common?orig
field always present?error
message always sent in direct response to a client request?error
field on thewelcome
message, and which values are common?The text was updated successfully, but these errors were encountered: