Breaking SymmetricHashJoin in Comunica due to missing this.match

[jacoscaz]

Hello!

While working on quadstore, which uses a custom configuration of Comunica as its SPARQL engine, I've encountered the following error:

/Users/jacoscaz/Repositories/node-quadstore-comunica/index.bundle.js:8682
        return !this.left.ended  || !this.right.ended || this.matchIdx < this.matches.length;
                                                                                      ^

TypeError: Cannot read property 'length' of null
    at SymmetricHashJoin.hasResults (/Users/jacoscaz/Repositories/node-quadstore-comunica/index.bundle.js:8682:87)
    at UnionIterator.<anonymous> (/Users/jacoscaz/Repositories/node-quadstore-comunica/index.bundle.js:8677:48)
    at UnionIterator.emit (events.js:315:20)
    at UnionIterator._changeState (/Users/jacoscaz/Repositories/node-quadstore-comunica/node_modules/asynciterator/dist/asynciterator.cjs:99:26)
    at UnionIterator._end (/Users/jacoscaz/Repositories/node-quadstore-comunica/node_modules/asynciterator/dist/asynciterator.cjs:200:18)
    at /Users/jacoscaz/Repositories/node-quadstore-comunica/node_modules/asynciterator/dist/asynciterator.cjs:212:34
    at internal/process/task_queues.js:149:7
    at AsyncResource.runInAsyncScope (async_hooks.js:197:9)
    at AsyncResource.runMicrotask (internal/process/task_queues.js:146:8)

This happens in the SymmetricHashJoin#hasResults() method, at the following line:

https://github.com/joachimvh/asyncjoin/blob/653424b38aa6801ddd1e3ab79ab99ea5a47b73ea/join/SymmetricHashJoin.js#L42

This only happens when I run rdf-test-suite with the SPARQL 1.0 suite and does not happen with the SPARQL 1.1 suite and/or quadstore's own tests.

The following modification seems to work:

return !this.left.ended  || !this.right.ended || (!!this.matches && this.matchIdx < this.matches.length);

@rubensworks for reference, this is the issue that got me to temporarily remove the actor-rdf-join-symmetrichash actor from quadstore-comunica.

Now - I'm not quite sure as to whether the edit above constitutes an actual fix or an ugly workaround to a problem that originates elsewhere. In the former case, I'd be happy to open a PR. If the latter, I would welcome any suggestion you might have as to where to start from with further debugging.

[joachimvh]

Disclaimer: it's been a while since I worked on this code so I might have forgotten some details.

It could be an indication something goes wrong (one of the input streams emitting an end event twice, data being read once the joined stream has ended), or it could be a race condition. The case I'm thinking of is a read being called on the stream when the two input streams have ended but their emitted end event still being on the call stack which could cause the joined stream to clean up before it received those events.

Either way, unless someone wants to dive deeper into this issue I'm ok with doing the suggested modification.