feat: idle syncing

[TalDerei]

uses chrome.alarms API to restart the service worker after extended periods of inactivity and make sync progress over time without any frontend providers or the extension being opened. This ensures the chain is already synced when the user returns to penumbra after that extended period of not using it. We aptly name this 'idle syncing'.

• accompanying context doc: https://docs.google.com/document/d/18awgAeCIhwVLmfKj_R7pXoFTNtcOMtdtKhCWRs0iDgE/edit?tab=t.0
  (this a long winded sanity check for sidestepping a major refactor to our connection lifecycle)

cc @hdevalence

---

when adding an event listener to log details as the alarm triggers (set periodInMinutes to 1 minute) and inspecting the service worker immediately after manually terminating it with chrome.runtime.reload(), it appears to working at first glance. However, we should contemplate potential pitfalls with this approach.

see #269 (comment) for an example

[TalDerei]

dynamically adjustable param

[erwanor]

FWIW, I think it will have to be much shorter than this (between 20 seconds and 4 minutes)

https://developer.chrome.com/docs/extensions/develop/concepts/service-workers/lifecycle

[erwanor]

I don't totally understand what causes the service worker to terminate, if it's long-polling the compact block stream or real idling.

[TalDerei]

FWIW, I think it will have to be much shorter than this (between 20 seconds and 4 minutes)

alarms can now be set to a minimum period of 30s to match the service worker lifecycle: "starting in Chrome 120, the minimum alarm interval has been reduced from 1 minute to 30 seconds"

I've been testing locally with 1 minute.

[hdevalence]

One test that comes to mind is, with each version of the code (pre and post change):

1. ensure no frontends or any other tabs are open
2. clear cache to reset view state
3. immediately quit chrome (to kill the service worker)
4. start chrome, do not open any tabs or frontends, wait 1h
5. open minifront
6. observe the current sync progress on minifront opening

(a custom chrome profile may be helpful here)

If background syncing is working we expect the post-change test to have significantly higher sync height at (6). Exactly how much is less important — as long as it's increasing we have reason to believe it will catch up and stay up to date.

[TalDerei]

per the docs: "starting in Chrome 117, the number of active alarms is limited to 500. Once this limit is reached, chrome.alarms.create() will fail. When using a callback, chrome.runtime.lastError will be set. When using promises, the promise will be rejected."

seems like a necessary extension to this might be to periodically clear all alarms using chrome.alarms.clearAll() in an event listener.

[turbocrime]

i considered alarms unnecessary because every content script (meaning every page load) will attempt to message the extension background with an init message, to connect pre-authorized origins. this message should wake up the extension background.

the init process changed a lot and things are scoped differently now, so probably at this point it just wakes up enough scope to handle the message listener callback, which doesn't access services. meaning service init is actually skipped.

the simplest way to handle this with alarms is, create an alarm with periodInMinutes, and a listener, in service-worker.ts. call CRSessionManager.init in the callback, and leave the current call where it is, so it also starts up immediately without waiting for the alarm.

CRSessionManager maintains a global singleton state that should prevent creation of multiple session managers. you should confirm this works the way i expect. if it doesn't, maybe you can assign the return value of CRSessionManager.init to a top-level variable.

it should be possible to refactor this in a way that avoids alarms and any new alarm permission, by refactoring the init message handler to require the return value of CRSessionManager.init to be in scope, or to execute CRSessionManager.init with a similar technique. the simplest way to do that would just mean relocating the content of listeners/content-script/init.ts into service-worker.ts so a top-level value can be captured in its callback's closure.

[TalDerei]

hey!!

i considered alarms unnecessary because every content script (meaning every page load) will attempt to message the extension background with an init message, to connect pre-authorized origins. this message should wake up the extension background.

...

it should be possible to refactor this in a way that avoids alarms and any new alarm permission, by refactoring the init message handler to require the return value of CRSessionManager.init to be in scope, or to execute CRSessionManager.init with a similar technique. the simplest way to do that would just mean relocating the content of listeners/content-script/init.ts into service-worker.ts so a top-level value can be captured in its callback's closure.

so the CRSessionClient is used by content scripts that's injected by the extension and run in the context of the web page, and the content scripts initiate connections to the manager, which causes chrome to queue the connection request while the service worker initializes.

but, the use case we're targeting is when the user doesn't open the extension and load a frontend for prolonged periods, which wouldn't trigger any content script init messages, and thus make no sync progress while the user's been offline.

the simplest way to handle this with alarms is, create an alarm with periodInMinutes, and a listener, in service-worker.ts. call CRSessionManager.init in the callback, and leave the current call where it is, so it also starts up immediately without waiting for the alarm.

thought the same thing initially, but in practice just creating the alarm is sufficient to wake up the service worker and kickstarting init - seems we don't need to put CRSessionManager.init inside a listener.

CRSessionManager maintains a global singleton state that should prevent creation of multiple session managers. you should confirm this works the way i expect. if it doesn't, maybe you can assign the return value of CRSessionManager.init to a top-level variable.

yeah, CRSessionManager's singleton pattern prevents multiple session managers, so subsequent calls just return the existing sessions map.

---

alarms are a nice idiomatic solution for periodically waking up the service worker. I do wonder however how the additional permissions will impact chrome store reviews.

[turbocrime]

an alarm is definitely the idiomatic way to do it. i expect reviewers may take issue with a high frequency.

worker kill conditions seem deliberately under-documented, and the conditions explained (pending fetch, pending promise resolution) are definitely something that the present behavior should meet. so at some point it's killed despite meeting the no-kill conditions.

i would investigate how long the worker runs if it's activated by the alarm but conducts no other activity, and experiment with setting an alarm

• just before that time
• just after that time
• much after that time

to identify the lowest effective frequency. even if there is a significant kill time between, if it can catch up before the next kill, the frequency can be reduced.

then document and justify the alarm reason as much as possible for the reviewers and users.

[TalDerei]

One test that comes to mind is, with each version of the code (pre and post change):

@hdevalence replicated the procedure on my older 2020 m1 pro – the browser cache was cleared, and neither any frontends nor the extension were opened.

Screen.Recording.2025-01-22.at.4.18.52.PM.mov

after starting chrome and waiting 10 minutes, it synced the entire chain (with alarms firing every minute). Previously, it would have just blocked on genesis sync during service worker init without making any progress.

Screen.Recording.2025-01-22.at.4.29.37.PM.mov

---

BETA TESTERS will replicate this waiting 1 hour instead.

[hdevalence]

Well, if the alarm approach solves the sync problem, that seems like a good improvement, and we could continue to refine it over time. A 30 minute alarm seems low frequency but we can find out if there are objections.

[TalDerei]

Well, if the alarm approach solves the sync problem, that seems like a good improvement, and we could continue to refine it over time. A 30 minute alarm seems low frequency but we can find out if there are objections.

an overnight test with a 30 minute frequency successfully kept up with the chain, and it was fully synced when I checked this morning. We just need to avoid falling behind, so if there's ~360 blocks / 30 min (current block times), then we only need to process ~12 blocks / sec if we assume the service worker has access to 30 seconds of execution every 30 min.

---

[TalDerei]

note to reviewers: this will be staged in #263, cut as part of the next prax v15.1 minor point release, and shared with beta testers.

[TalDerei]

for checking beta reviewer logs

[erwanor]

This shows up in the service worker console right? not the main web one

[TalDerei]

logs display in both since chrome forwards the service worker logs to the main extension console

chrome forwards the service worker logs to the main extension console, but it won't show up in the web browser's console.

[erwanor]

Cool, good work. I think we should get this in the hands of beta testers asap. The wake up frequency seems polite and reasonable so I hope Chrome review won't object.