Strange infinite recursion bug (tabs.onActivated, useWebExtensionStorage, browser.tabs.get, browser.storage.local.addListener, watchWithFilter)

[adao]

I'm not sure what is the perpetrator here. I kept running into this recursive error that happened when I was using useWebExtensionStorage. I finally "fixed" it in my app by adding the debounceFilter when using useWebExtensionStorage. I wasn't satisfied, so I fired up fresh vitesse-webext project to see if I could re-produce and investigate from there. Finally, I got it down to the bare minimum to reproduce the bug.

To reproduce:

Add to ~/logic/storage

export const objectDemo = useWebExtensionStorage('objectDemo', {})

Add these listeners in ~/src/background/main.ts

browser.runtime.onInstalled.addListener((): void => {
  console.log('Extension installed')
  objectDemo.value = {}
})

let previousTabId = 0
browser.tabs.onActivated.addListener(async ({ tabId }) => {
  console.log('tab activated')
  // const tab = await browser.tabs.get(tabId)

  if (previousTabId) {
    objectDemo.value[previousTabId].status = 'inactive'
    objectDemo.value[previousTabId].updatedAt = new Date().toISOString()
  }

  if (objectDemo.value[tabId]) {
    objectDemo.value[tabId].status = 'active'
    objectDemo.value[tabId].updatedAt = new Date().toISOString()
  } else {
    const tab = await browser.tabs.get(tabId)
    objectDemo.value[tabId] = {
      name: tab.title,
      status: 'active',
      updatedAt: new Date().toISOString(),
    }
  }
  previousTabId = tabId
})

And in useWebExtensionStorage.ts, add a console.log('storage changes', changes) to your storage listener function and a console.log('data changes', data.value) to your watchWithFilter function.

Now load the extension, open up your service worker console, and navigate between any two tabs. It happens after 3 total tab navigations that I begin seeing an infinite loop of console.log statements. Be ready to quickly turn off the extension or else it's going to start eating up your CPU.

And I've found a very bizarre fix for this. If someone could explain it to me, because it's beyond me at this point. In the browser.tabs.onActivated listener, if I move the instantiation of tab, const tab = await browser.tabs.get(tabId) to the beginning of function instead of in the else block, no infinite loop.

So weird!!! Even though the bug goes away, I don't consider it a fix at all.

I set up the repo here if anyone wants to pull and explore

[gxr404]

• const tab = await browser.tabs.get(tabId) moves to the beginning watch executed once. Example

• Execute twice without moving. Example

two write reactive data:

/** 
 if (previousTabId) {
    objectDemo.value[previousTabId].status = 'inactive'
    objectDemo.value[previousTabId].updatedAt = new Date().toISOString()
  }
**/
{
"1982090497":{"name":"page1","status":"inactive","updatedAt":"2024-06-25T14:40:36.452Z"}
}
// await browser.tabs.get(tabId)
/**
 objectDemo.value[tabId] = {
      name: tab.title,
      status: 'active',
      updatedAt: new Date().toISOString(),
    }
**/
{
	"1982090494":{"name":"page2","status":"active","updatedAt":"2024-06-25T14:40:36.452Z"},
	"1982090497":{"name":"page1","status":"inactive","updatedAt":"2024-06-25T14:40:36.452Z"}
}

Recursive guessing is because:

reactive data change  {a:1} ->  watch ->  setItem localstorage  -> localstaroge change event ->  change reactive vue data -> at this point, reactive data {a:2} triggered the watch again -> infinite.....
reactive data change  {a:2} ->  watch ->  setItem localstorage ->  localstaroge change event  -> .....

Try fixing it:

  watchWithFilter(
    data,
    async () => {
      console.log('data changes', data.value)
      try {
        if (data.value == null) {
          storageInterface.removeItem(key)
          return
        }
        const currentStorageValue = await storageInterface.getItem(key)
        const setStorageValue = await serializer.write(data.value)

        if (setStorageValue !== currentStorageValue)
          storageInterface.setItem(key, setStorageValue)
      }
      catch (error) {
        onError(error)
      }
    },
    {
      flush,
      deep,
      eventFilter,
    },
  )

sorry， Poor English, not very clear expression 😂

[gxr404]

Hi, The previous statement contains an error.

As long as the read function is executed, it will definitely trigger the watch

Because every time the data is changed, a new object is re serialized

data.value = await serializer.read(rawValue) as T

Example

This explains why there will still be a data changes call in the end

Why does triggering a watch not result in a dead loop？

watch call ->   setItem localStorage  ->  localStorage change event  ->  change reactive vue data ->  setItem localStorage -> 
At this point, the "localStorage change event " will not trigger again, 
Because the current localStorage is consistent with the localStorage you want to set

The next two watch triggers:

watch call A -> setItem localStorage -> localStorage change event ->
change reactive vue data -> setItem localStorage ->
localStorage change event（At this point, the event was triggered again because the localStorage at this time is B, and the newly set value is A）

watch call B-> setItem localStorage -> localStorage change event ->
change reactive vue data -> setItem localStorage ->
localStorage change event（At this point, the event was triggered again because the localStorage at this time is A, and the newly set value is B）

...Infinite loop

next
Your warehouse example still has a dead loop when used

Changing it to this may make it more noticeable

   calls++
      if (calls > 40) {
        console.error('loop calls')
        return
      }

——————

I have tried various situations and found that

 watchWithFilter(
  ....
        // infinite loop 
         setTimeout(async () => {
           const setStorageValue = await serializer.write(data.value)
           storageInterface.setItem(key, setStorageValue)
         }, 0)

 watchWithFilter(
  ....
        // normal
         setTimeout(async () => {
           const setStorageValue = await serializer.write(data.value)
           storageInterface.setItem(key, setStorageValue)
         }, 100)

 watchWithFilter(
  ....
       
        const setStorageValue1 = await serializer.write(data.value)
        const currentStorageValue = await storageInterface.getItem(key)
        const setStorageValue2 = await serializer.write(data.value)
		 // infinite loop 
		// storageInterface.setItem(key, setStorageValue1)
        // normal
		storageInterface.setItem(key, setStorageValue2)

This means that Inconsistent serialization between setStorageValue1 and setStorageValue2 during two triggers

Why is await storageInterface.getItem(key) effective ?

I guess await storageInterface.getItem(key) will wait until the last successful setItem before returning

watch call A -> setItem localStorage -> localStorage change event ->
change reactive vue data (Serialize fresh data after waiting for the previous setItem(B) (!! data.value is B)) -> setItem localStorage ->
localStorage change event （Not triggered because localStorage is still B, and the newly set one is also B）

watch call B-> setItem localStorage (wait previous setItem(A) ( fresh data.value is B)) -> localStorage change event ->
change reactive vue data -> watch call B -> setItem(B) -> localStorage change event （Not triggered because localStorage is still B, and the newly set one is also B）

Of course, my statement may not be correct. Feel free to give me your advice 😂

[adao]

Ah! Yes, thank you. Now I understand the root of the recursion. There were a few things wrong with my debugging code 😅

Strange — I thought await new Promise((resolve) => resolve()) really was fixing it. Maybe it was a fluke yesterday (or I had a bug in my debugging), but yeah, it's not working now. Not to mention, I was console.logging toRaw(data.value) which ended up being a reference and so not helpful to look at.

According to my new debug logs, I think watch calls actually go like

watch call A -> setItem localStorage (!! data.value is B) -> localStorage change event ->
change reactive vue data -> setItem localStorage ->
localStorage change event （Not triggered because localStorage is B, and data.value is also B）

watch call B-> setItem localStorage (data.value is B)) -> localStorage change event (Not triggered because localStorage is B, and data.value is also B）

[adao]

I don't think getItem necessarily waits for the last setItem. Or, even if it does, I don't think that's why the code is working here.

I think it's that the wait is long enough for Javascript to continue executing other code, and when it comes back to execution, data.value is already set to B. According to my logs, watch call B doesn't call setItem before watch call A's getItem call.

Here's my output

call 6 is "A" (executes code up until getItem)
call 7 is "B" (executes code up until getItem)
call 6 executes code from getItem up until setItem (at this point, data.value is what you would expect in B)
call 7 executes code from getItem up until setItem
call 8 (watch call "C" from A setting reactive Vue data in read function)

[gxr404]

You're right, it really has nothing to do with await storageInterface.getItem(key), just wait is long enough

I just don't think the solutions for await storageInterface.getItem(key), and debounceFilter are very suitable.

How long to wait is suitable, depending on the user's environment and whether the computer equipment is relevant？

I checked the code of vueuse/useStorage

I found that the direction was completely wrong 😅

• Watch reactive data is used to change the localstorage
• localstorage addListeneris used to change reactive data

Does the data modified through Watch reactive not need to be modified through localstorage addListener anymore

localstorage addListener paused Watch listening when triggered, only changing the reactive data

The final solution:

import { StorageSerializers, pausableWatch } from '@vueuse/core'
....

  async function write() {
    try {
      await (data.value == null ? storageInterface.removeItem(key) : storageInterface.setItem(key, await serializer.write(data.value)))
    }
    catch (error) {
      onError(error)
    }
  }

 const { pause: pauseWatch, resume: resumeWatch } = pausableWatch(
    data,
    write,
    { flush, deep, eventFilter },
  )
const listener = async (changes: Record<string, Storage.StorageChange>) => {
      console.log('storage changes', JSON.parse(changes.object.newValue))

      pauseWatch()
      try {
        for (const [key, change] of Object.entries(changes)) {
          await read({
            key,
            newValue: change.newValue as string | null,
          })
        }
      }
      finally {
        resumeWatch()
      }
    }

...

I think this may be a more reliable approach. Do you think so 😂

[adao]

😭

this looks perfect!

[adao]

Success! Thanks @gxr404 !