Debounce state updates

[Mrtenz]

This changes the persisting logic in the Snap Controller to debounce state updates for each Snap individually by 500 milliseconds. This means that if the Snap updates state multiple times within 500 milliseconds, the state is only persisted once, 500 milliseconds after the last update.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 94.98%. Comparing base (fdc83e1) to head (0b35b76).
Report is 1 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #3258   +/-   ##
=======================================
  Coverage   94.98%   94.98%           
=======================================
  Files         511      511           
  Lines       11299    11313   +14     
  Branches     1738     1741    +3     
=======================================
+ Hits        10732    10746   +14     
  Misses        567      567           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[Mrtenz]

Marking as draft because this needs some further discussion about the debounce timeout.

[GuillaumeRx]

Does this means we merge updates or that we skip one if they are sent too close to each others ?

[Mrtenz]

Does this means we merge updates or that we skip one if they are sent too close to each others ?

@GuillaumeRx We always persist the entire state object, not partial updates. If there are multiple state updates in a row, we only persist the last (most up to date) one now.

[GuillaumeRx]

Does this means we merge updates or that we skip one if they are sent too close to each others ?

@GuillaumeRx We always persist the entire state object, not partial updates. If there are multiple state updates in a row, we only persist the last (most up to date) one now.

I guess this is okay as this does not really change how the API previously worked but I'm worried that Snaps making multiple non-related updates to the state in a row might start having some state updates missing ? 🤔

[FrederikBolding]

Does this means we merge updates or that we skip one if they are sent too close to each others ?

@GuillaumeRx We always persist the entire state object, not partial updates. If there are multiple state updates in a row, we only persist the last (most up to date) one now.

I guess this is okay as this does not really change how the API previously worked but I'm worried that Snaps making multiple non-related updates to the state in a row might start having some state updates missing ? 🤔

It should only be the persistence that is affected, the actual state update is put into memory right away

[FrederikBolding]

I just realized, we should debounce per Snap ID and encrypted true/false otherwise we will have data loss with this

[Mrtenz]

Good catch, didn't think about encrypted true/false.