[BUG] An unexpected error occurred (Could not establish connection. Receiving end does not exist)

[rolznz]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

Clicking on the extension icon while logged in sometimes throws and error and shows a logged-out state

Screenshots [optional]

Steps To Reproduce

First Issue:

1. Checkout and build the latest master branch (yarn run dev:chrome)
2. Login to the extension
3. Close the popup
4. Switch to a different application
5. Go back to your browser and click the Alby extension icon

Second issue:

1. Log into the extension with multiple accounts
2. Switch from LND to an Alby hosted account (2nd screenshot)

Expected behavior

The popup opens and you are still logged in, with no errors. You can also switch accounts without errors.

Alby information

• Master branch (latest)

Device information

Chrome Windows

Additional context

May be related to the recent manifest version 3 update

Are you working on this?

None

[reneaaron]

You can stop any service worker manually by visiting the service worker page to reproduce this problem.

➡️ chrome://serviceworker-internals/?devtools

[rolznz]

This URL is a bit better for managing the service worker: chrome://inspect/#service-workers

[kamalbuilds]

Hi , can I work on this issue ? I am able to reproduce it . I think there is an issue with state and can try to resolve it .

Thanks.

[kamalbuilds]

Ok @rolznz cool , If you wanna take on it 👍🏻

[rolznz]

@legendarykamal if you are able to find the fix for this, great! I assigned it to me as we need to find a fix before the next release, and we are actively working on it.

[rolznz]

Notes:

This issue started appearing in this merge commit: dd85f9a

My investigation so far:

When the service worker is terminated and re-launched, it takes some time to start up. The startup runs the full background script init() all over again.
The account context and settings context are sending messages before browser.runtime.onMessage.addListener(routeCalls); is called in background-script.init.
I managed to "fix" it by putting that line right at the top of the init function, but of course that will have other issues because it starts accepting messages when e.g. the db is not ready.
I am still not sure why the commit above caused the issue to start happening. But maybe if this is standard behaviour, then we should be waiting for the background script to initialize before requesting, or we can identify that the background script hasn't started and then re-do the failed request?

CC @escapedcat

[rolznz]

We either need to fix this issue or revert the MV3 changes, because after we deploy them there is no way to go back.