Introduced functionality for releasing the navigator lock#545
Introduced functionality for releasing the navigator lock#545Chriztiaan wants to merge 2 commits intomainfrom
Conversation
🦋 Changeset detectedLatest commit: a54a914 The changes in this PR will be included in the next version bump. This PR includes changesets to release 2 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
| } | ||
|
|
||
| // Clearing the adapter will result in a new one being opened in connect | ||
| await trackedPort.clientProvider.releaseSharedConnection(); |
There was a problem hiding this comment.
For my own understanding: Where would we release the lock otherwise? Through trackedPort.db.close()?
I don't have a good mental model of how we're sharing connections here, but I'm worried about whether it's possible for us to release the shared connection here and someone else then re-obtaining the lock on a different connection? (so we'd have two of them when it sounds like we probably only want to have one).
If the lock is only held to avoid the tab being put to sleep as the comment suggests, why aren't we just requesting a randomly-named lock?
There was a problem hiding this comment.
If the lock is only held to avoid the tab being put to sleep as the comment suggests, why aren't we just requesting a randomly-named lock?
You are the second person to suggest this. I think you're spot on here.
|
Closed in favour of #546 |
3 participants
In some cases for web with multiple tabs support enabled, multiple 'connect()` calls in a single tab happening in succession can cause a navigator lock to be stuck in an unreleased state. This blocks the sync worker from getting a connection and syncing/connecting breaks.
Two typical scenarios that can cause this is switching client parameters and React's StrictMode which does multiple calls of hooks like useEffect.
Cherrypicked commit from @stevensJourney.