Multiple Assertion Failed !!

[LRagji]

I am using node runtime 12.20.0 & 12.18.3 on a Windows 10 & Mac 10.14.6 machine with following code, which is resulting in lot of Assertion Failed Messages:

var level = require('level-party')
var db = level(__dirname + '/data', { keyEncoding: 'binary', valueEncoding: 'json' })
const start = Buffer.allocUnsafe(8);
start.writeBigInt64BE(1n, 0);
const end = Buffer.allocUnsafe(8);
end.writeBigInt64BE(2n, 0);
let x = new Promise((a, r) => {
    db.createReadStream({ gte: start, lte: start })
        .on('data', function (data) {
            console.log(data.key, '=', data.value)
        })
        .on('error', function (err) {
            console.log('Oh my!', err)
            r();
        })
        .on('close', function () {
            console.log('Stream closed')
            a();
        })
        .on('end', function () {
            console.log('Stream ended')
            a();
        })
});
x.then((e) =>
    console.log("Done")
)

Message 1: Assertion Failed at binding.cc @ 545
Message 2:Assertion Failed at version_set.cc @ 798

[vweevers]

Does it still happen if you remove:

.on('end', function () {
	console.log('Stream ended')
	a();
})

Because the end event, which means there's no more data to read, is fired before close, which means the underlying iterator was closed at which point it's safe to exit the process. If you resolve the promise on end, it's not yet safe to exit.

Since node 12, node calls finalizers on process exit and we've yet to implement a proper hook to account for this (see #667 and nodejs/node#28428). Without such a hook we hit the _ended assertion shown in your screenshot, which asserts that the iterator was properly closed (either by the stream that wraps it, or through closing the db) before it's finalized.

[LRagji]

@vweevers as suggested ran by removing on "end" event still fails, additionally tried it on Mac as well with node 12.18.3 still fails with same assertions..

A creepy workaround that i found was to give some time before exiting node process by using setTimeout of 5 seconds which exits normally... i think there are some events in node loop which are not processed when the process exits immediately...

[vweevers]

That's not good. Does it also happen if you replace var level = require('level-party') with var level = require('level')?

[LRagji]

Ok this is interesting, using level package doesn't give this problem both are at 6.0.1 version...

[TanninOne]

I'm getting the same errors on Windows 10 with leveldown 5.6.0 (no level-party)
Not sure if this helps but I get these when loading a leveldb that was previously written by leveldown 5.4.1.
I'm using two versions of my app, one using leveldown 5.4.1 the other 5.6.0 and the assertions only happen the first time running the newer version after I had run the older one.
After that if I stay on the newer version it doesn't occur, running the older version is ok but then going back to the new one causes the crash again.
It doesn't seem like any data gets lost in this.

In my system it happens during "createReadStream" but not right away, it seems to happen a random time after the stream was opened and a few items were returned.

Also I tried adding a delay before the call to createReadStream because I had a feeling it was a timing problem but that has the effect that the process dies silently instead of producing the assertion errors.

EDIT: the above may be a red herring. I downgraded leveldown, levelup and encoding-down to be exactly the same between the newer and older version of my application and still the newer version exposes the problem when reading the db from the older one for the first time.
Sooo, I guess it's related to the node.js version? (electron 11.2.2/node 12.18.3 vs electron 8.5.2/node 12.13.0)

[TanninOne]

I've rebuild leveldown (5.6.0) so I get pdbs and debugged this a bit.
What I can say at this point is that on the C side FinalizeIterator gets called on an iterator for which no onEOFChunk (and thus Iterator.prototype._end from iterator.js) was called before, so the iterator gets garbage collected before the stream is done processing.

I can trigger the crash fairly reliable in my environment but I can't really say what'd be necessary to reproduce it, if I can provide any more information that would help I'd be happy to do so.

EDIT: ooof, this was quite a bit more trivial than I thought. So what happens is that during the upgrade from the old version of my application to the new one it restarts itself. This happens asynchronously and it just so happens that the db stream is still being read. This triggers - as described above - the iterator to be garbage collected before the stream is done reading which in turn triggers the assert(_ended). This then causes a crash and I never realized that my application was ending intentionally...

[LRagji]

Would this behavior be triggered when DB is empty? Say i said createstream for key range not existing? And for me why does level package work and not level-party is still a question 🤔