-
Notifications
You must be signed in to change notification settings - Fork 34
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
don't send ERROR:crowded in response to CLOSE #20
Comments
IMO that part is a bug on the client side: it sent a message and got an The relevant server side code appears to be this: if not self._mailbox:
try:
self._mailbox = self._app.open_mailbox(mailbox_id, self._side,
server_rx)
except CrowdedError:
raise Error("crowded") I don't understand: why are we opening a new mailbox in the first place? If there's no mailbox on close, simply ignore it as already closed? |
This seems like it could be related to what Im seeing right now on the public wormhole service. I recent was reusing the same The following behavior is what Im see this morning:
Then the following crowded error:
Again I can just use a new code but figured it was worth reporting since its fresh. Happy to open up another issue if thats more appropriate. |
I can confirm that reusing codes multiple times causes spurious "crowded" issues which could be related to this issue. I have no specific reproduction recipe, but I strongly suspect there is a race hazard involved. @sarcasticadmin please make sure that you know the security consequences of using a code multiple times and don't use this in production without counter-measures. |
@piegamesde thanks for the clarification
Yep, absolutely. It was just for testing and pure laziness so I didnt have to keep updating inputs. |
In magic-wormhole/magic-wormhole#408 I think a client received
ERROR(crowded)
(eventually, because of #19, so only after the server was rebooted and the client reconnected, and re-sent the OPEN), and then tried to release the mailbox by sending CLOSE, but was thwarted because the server sent back anotherERROR(crowded)
. I think the client then got stuck, unable to exit (because it thinks it still has a hold on the mailbox), not sending a new CLOSE (because it already sent one and it's just waiting for CLOSED).The fix is probably to have
handle_close()
(in the clause that doesself._app.open_mailbox()
, because this connection didn't have one already) react toCrowdedError
by doing most of the rest of the function, instead of raisingError("crowded")
. We can't do anything that touchesself._mailbox
, since we don't have one, but we can setself._did_close
and (most importantly) doself.send("closed")
. That should satisfy the unsettled ghost client and allow it to finally exit.The text was updated successfully, but these errors were encountered: