Refreshing page causes y-indexeddb to accumulate db entries

I have a standard call to y-indexeddb in a web app , e.g.

	const persistence = new IndexeddbPersistence(room, doc)
	// once the map is loaded, it can be displayed
	persistence.once('synced', () => {
		console.log(' local content loaded')

When I look in DevTools at Application > IndexedDB > [room] > updates, I see 2 rows, one for a Uint8Array[0,0,buffer: arrayBuffer(2)...] and one long Uint8Array.

If I now refresh the page in the browser (without making any changes to the doc), another two rows are added (similar to the first two). Each refresh adds another two rows. Is this the expected behaviour? Since the data to be stored hasn’t changed, I wasn’t expecting any change to the database.

(The motive for asking this question is that I am experiencing some unreliability in retrieving the contents of a yDoc when I use both y-indexedDB and y-websocket, and I am trying to track down the cause).

@micrology, are you using Firefox? probably related to this, Y-websocket-server connection event emitted twice on page reload

This occurs on Chrome and Safari as well as Firefox (on a Mac, Monterey), so I don’t think there is a link to that issue. Also I am logging connection events and I don’t see it emitted twice.

Here is a minimal example:

import * as Y from 'yjs'
import {IndexeddbPersistence} from 'y-indexeddb'

const doc = new Y.Doc()
const persistence = new IndexeddbPersistence('test11-2', doc)
persistence.once('synced', () => {
	console.log(` ${yMap1.get('prop1')} loaded from IDB`)
const yMap1 = doc.getMap('map1')
yMap1.set('prop1', 'foo')

If you run this, and look in the Debugger at the display for IndexedDB, every time the page is reloaded, a new key and value is generated for database test11-2, object store updates. This is true in both Chrome and Firefox.

This happens here as well, but it doesn’t seem to cause any issues. What kinds of unreliabilities are you experiencing?

I have a yDoc that can often be 3MB or more. Reloading this a good few times uses a lot of memory since 3MB is added each time. I suspect that the problem a client had with my app was caused by IndexedDB being ‘out of memory’ (or out of disk space), but it was not possible to reproduce the issue. Whether or not that was the case, I don’t understand why we are seeing this behaviour.


@micrology did you find a solution for this? I’m also facing the same issue and checking how to resolve it.