Bug Report

Steps to Reproduce:

1. In a node.js backend, we create a new table called table and add some rows. We are viewing this in the browser through a seperate frontend app, connecting via websocket.
2. In the backend, we call table.remove(keys) on with one or more keys (a small fraction of the data).
3. In the browser frontend, using the search functionality to e.g. filter for a particular row (on the value of a primary key, for example) we are shown an incorrect row.

Expected Result:

The filtered row should obey the filter.

Actual Result:

Another row is displayed. For example a == filter on a primary key displays exactly one row, but it is actually one of the neighboring rows with a different (slightly offset) primary key.

Environment:

Node 12, Perspective 0.4.6, Google Chrome 80.0.3987.149

Additional Context:

Reloading the browser window does not fix the problem - so whatever is going on, I suspect it has more to do with the Table in node rather than the View in the browser.

I haven't yet looked into the implementation of perspective (what's a gnode?)... but given it is so fast, I suspect there are some secondary acceleration indices maintained on the table columns, and the observed behaviour is consistent with these not being updated correctly when a row is removed. E.g. perhaps internally the filter finds the index to a row through the acceleration index, but this is somehow offset to the real data. It doesn't seem to matter which column we filter on - primary key or not (one example had multiple columns that happened to be unique, and filtering on any of them returned the same incorrect row).

Here's an example where Job.Code is offset by 2. (I get the same row when I filter on the corresponding Job.ID instead).