The attached trace shows 600k tasks in the db task queue. I guess each task writes to the database and takes too long. This ends up keeping ~150MB in memory for that long. Is there anyway to have a cache and not update db everytime?
These cases where spam happens, usually the url or the origin is same. Maybe we could use that?

Do you know of (or could construct) a test page I can visit to repro this behavior?

That would help in designing and testing a fix.

In principle we could probably cancel some earlier tasks in favor of later ones, but a couple things make this challenging.  First, because there's already batching, we might be posting tasks including multiple updates rather than single ones, so we can't necessarily cancel earlier tasks outright.  Second, we could only safely cancel if the earlier writes would be completely overwritten by later ones (i.e. not changing any fields not changed in the later tasks).

Depending on how fast the page is generating updates, a simple way to bypass the above issues might just be to change code like this:

enter batch mode
add changes to queue
flush batch mode

to this:

enter batch mode
add changes to queue
if no such task already exists, post a 5 sec-delayed task to flush batch mode

This would collect updates into 5-second windows before posting them to DB tasks.  There could be shutdown consequences here (we'd probably want to detect shutdown and flush immediately).

This bug has an owner, thus, it's been triaged. Changing status to "assigned".