-
Notifications
You must be signed in to change notification settings - Fork 45
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
rpcc.Conn.Close returns an error if the target is already closed #110
Comments
I see what you mean, I hadn't considered closing a target before the |
Hi Mathias, thanks for quick response! It's great if Since the websocket connection is bi-directional, it should be closed the both party (client and server). And there's no strict requirement on which party to initiate closing the connection. If the server (browser) gracefully closes the connection first, the client (cdp) has to close the connection as well, and I don't expect it to result in an error (of course, if there is in-flight method calls, they should fail with errors). What do you think? |
…ri#110) rpcc.Conn.Close calls Target.DetachFromTarget before closing the websocket connection, which fails if the target is already closed. This is a bit inconvenient because we have to ignore errors from rpcc.Conn.Close when we close the target in advance, which means that we might miss other interesting errors. This change updates the detach function to ignore errors on Target.DetachFromTarget calls if it is because the target is already gone.
…ri#110) rpcc.Conn.Close calls Target.DetachFromTarget before closing the websocket connection, which fails if the target is already closed. This is a bit inconvenient because we have to ignore errors from rpcc.Conn.Close when we close the target in advance, which means that we might miss other interesting errors. This change updates the detach function to ignore errors on Target.DetachFromTarget calls if it is because the target is already gone. Also adds a unit test to test this behavior. FIXME: The unit test still does not pass.
This is a naive attempt to ignore "No session with given id" error on DetachFromTarget call: However it does not pass my new unit test with the following error:
IIUC it is because |
rpcc.Conn invokes Target.DetachFromTarget before closing the connection, which fails if the target is already closed. This error is not a real problem, but it can confuse cautious callers who check errors of Close. See also an upstream bug: mafredri/cdp#110 BUG=chromium:1020484 TEST=tast run betty ui.ChromeSanity Change-Id: I0fb1e50a683e493195874344c07f66a8ecefd40e Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/tast-tests/+/1903152 Tested-by: Shuhei Takahashi <nya@chromium.org> Commit-Queue: Shuhei Takahashi <nya@chromium.org> Reviewed-by: Hidehiko Abe <hidehiko@chromium.org>
rpcc.Conn invokes Target.DetachFromTarget before closing the connection, which fails if the target is already closed. This error is not a real problem, but it can confuse cautious callers who check errors of Close. See also an upstream bug: mafredri/cdp#110 BUG=chromium:1020484 TEST=tast run betty ui.ChromeSanity Change-Id: I0fb1e50a683e493195874344c07f66a8ecefd40e Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/tast-tests/+/1903152 Tested-by: Shuhei Takahashi <nya@chromium.org> Commit-Queue: Shuhei Takahashi <nya@chromium.org> Reviewed-by: Hidehiko Abe <hidehiko@chromium.org> (cherry picked from commit 38ffaee) Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/tast-tests/+/1914886 Reviewed-by: Shuhei Takahashi <nya@chromium.org>
rpcc.Conn.Close
returns an error if the target is already closed, e.g. by invokingcdp.Client.Target.CloseTarget
. This is a bit inconvenient because we have to ignore errors fromrpcc.Conn.Close
when we close the target in advance, which means that we might miss other interesting errors.The text was updated successfully, but these errors were encountered: