query A recomputes, and executes the callback.
In this callback, it destroys query B.
However, query B is still enqueued, so it recomputes and executes its callback anyway (which is probably invalid after query A destroyed it).
I need to see a concrete reproduction of the issue. Because the line if (txId === lastComputedTxId) return should take care of any issues like this so it doesn't emit more than once.
The following situation arises in tuple db:
subscribe query A subscribe query B
some transaction is committed.
callback A is enqueued callback B is enqueued
query A recomputes, and executes the callback. In this callback, it destroys query B. However, query B is still enqueued, so it recomputes and executes its callback anyway (which is probably invalid after query A destroyed it).
This PR fixes that situation.