1626585 - "Protocol error (noSuchActor): No such actor for ID" when closing the devtools

Status: VERIFIED FIXED

(DevTools :: General, task, P3)

Description

[Itiel]

STR:

1. Open any page
2. Ctrl+Shift+J
3. Ctrl+Shift+C, wait for the Inspector to fully load
4. Close the devtools
5. See on the browser console the following error:

Error while detaching the worker target front: Error: "Protocol error (noSuchActor): No such actor for ID: server1.conn0.workerTarget174 from: server1.conn0.workerTarget174"   worker.js:94:15
    onPacket resource://devtools/shared/protocol/Front.js:319
    DevTools RDP*request resource://devtools/shared/protocol/Front.js:256
    name resource://devtools/shared/protocol/Front/FrontClassWithSpec.js:47
    detach resource://devtools/client/fronts/targets/worker.js:92
    _destroyTarget resource://devtools/client/fronts/targets/target-mixin.js:461
    destroy resource://devtools/client/fronts/targets/target-mixin.js:422
    _workerListChanged resource://devtools/shared/resources/target-list.js:193
    _emit resource://devtools/shared/event-emitter.js:226
    emit resource://devtools/shared/event-emitter.js:172
    emit resource://devtools/shared/event-emitter.js:324
    onPacket resource://devtools/shared/protocol/Front.js:294
    onPacket resource://devtools/client/devtools-client.js:493
    send resource://devtools/shared/transport/local-transport.js:68
    makeInfallible resource://devtools/shared/ThreadSafeDevToolsUtils.js:111
    makeInfallible resource://devtools/shared/ThreadSafeDevToolsUtils.js:111

Comment 1

[Jan Honza Odvarko [:Honza] (always need-info? me)]

Thanks for the report, I am seeing this error a lot.

Julian, is there anything we could do about this?

Honza

Comment 2

[BugBot [:suhaib / :marco/ :calixte]]

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Comment 3

[BugBot [:suhaib / :marco/ :calixte]]

The component has been changed since the backlog priority was decided, so we're resetting it.
For more information, please visit auto_nag documentation.

Comment 4

[Julian Descottes [:jdescottes]]

(didn't mean to clear the ni? while retriaging...)

Comment 5

[Julian Descottes [:jdescottes]]

The destroy codepath can get pretty complex :)

We still perform a lot of async operations during destroy, which means that it's hard to settle on a consistent codepath that will be used for every "target" that we detach. We need our code to work both when the toolbox is destroyed (devtools initiates the destruction) or when the target disappears (closing the tab for instance). And to support that, we often end up calling destroy/detach several times for a single target.

In this case what happens is that the WorkerTargetActor is destroyed on the server side first, and then destroying the corresponding WorkerTargetFront on the client side ends up calling this.detach() which will fail because the actor is already gone. This is something we expect and that's why the calls to detachare all wrapped in try/catch statements. The comment in target-mixin.js even mentions it: https://searchfox.org/mozilla-central/rev/a707541ff423ade0d81cef6488e6ecfa09273886/devtools/client/fronts/targets/target-mixin.js#456-459

I'm not really in favor of complexifying the destroy code to avoid calling detach() in some cases. However, maybe we should avoid logging errors if the error is about No such actor for ID, since it simply indicates the actor was already destroyed.

I'll put up a patch to do that and we'll see what others think.

Comment 6

[Julian Descottes [:jdescottes]]

Attachment: Bug 1626585 - Silence target front detach errors when actor is already destroyed

Comment 7

[Jan Honza Odvarko [:Honza] (always need-info? me)]

Great, thanks for picking this up Julian!

I agree with avoiding logging the errors - if they are actually not indicating any errors.

Honza

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/65596c106145
Silence target front detach errors when actor is already destroyed r=nchevobbe

Comment 9

[Daniel Varga [:dvarga]]

https://hg.mozilla.org/mozilla-central/rev/65596c106145

Comment 10

[Cristian Fogel [:cfogel]]

Confirmed issue with 76.0a1 (2020-04-01) on Windows 10.
Fix verified with 77.0b2 on Windows 10, macOS 10.15.3, Ubuntu 18.04.