The description in the blog post is not entirely correct. The SW was terminated at 30 seconds mark, not 5 minutes. The 5 minutes mark is the timeout of a runtime port or any ExtendableEvent and it remains intact. The problem that was fixed now is that the 30 seconds timer wasn't previously auto-prolonged by a `chrome` event in an already running service worker, which meant that SW would live for just 30 seconds since it was started. It was problem in cases when a new `chrome` event occurred at the end of the timeout and the code called an asynchronous API like fetch() or chrome.storage, which might take longer to complete than the remainder of the timeout so the SW would be auto-terminated without running the subsequent code of the event listener.
Consider this example:
chrome.action.onClicked.addListener(async tab => {
const ok = await (await fetch(API)).json();
chrome.action.setBadgeBackgroundColor({tabId: tab.id, color: ok ? GREEN : RED})
}); When the user clicked the icon and SW started for the first time, the badge was updated successfully. Then exactly 29 seconds later the user clicked again and fetch() took longer than the remaining one second so the SW terminates during `await` and the badge doesn't change and the user wastes time waiting for the extension's reaction, then clicks again, this time successfully. After seeing such randomly broken behavior a few times the user uninstalled the extension and/or gave it a bad rating.
Now that it's fixed, each new `chrome` event in an already running SW prolongs its lifetime by another 30 seconds. This addresses he majority of cases but it won't help with an API that takes longer than 30 seconds of course (that's outside the scope of the bug that was fixed), so you'll have to use a workaround to prolong the lifetime of the SW or do the work in a different context e.g. a web_accessible_resources frame added to the web page.