Open vic0824 opened 5 months ago
Could you try adding @rid
to the projection and see if the error persists?
I know the problem is the index, because if I drop the index and repeat the query, I get the correct results.
If I re-create the index, the query gives the correct result.
Could you try adding
@rid
to the projection and see if the error persists?
Sorry, I had already dropped and re-created the index when I've read your suggestion. I need to wait for the index to become corrupted again and then execute the select adding the rid. I'll let you know.
It has happened again: I attach:
I have to drop and re-create the index, to allow the workflow to proceed, so if you need me to perform any other tests I will need to wait for the issue to re-occur.
And it happened again. A common pattern is that it happens shortly after the bulk insert. I attach the method that performs the bulk insert; it create a temporary index, it inserts the records asynchronously, and then it drops the temporary index. insertOrdersAsync.zip
I have updated the issue title, as it appears to be linked to the bulk insert, rather than the update
Maybe this issue is linked to https://github.com/ArcadeData/arcadedb/issues/1509? Maybe it’s not “safe” to create an index while some records are being modified?
it could also be related to this: https://github.com/ArcadeData/arcadedb/issues/1391#issuecomment-2054066737. For some reason the new branch that reuses the RIDs can't pass (100% reproducible) a specific test case after an asynchronous insert. Maybe the issue is the combination of async and index.
ArcadeDB Version:
v24.1.1 (build 48e937e9a860ea97a7f245994a9df8bdb6af56d2/1707163239355/main)
OS and JDK Version:
Linux 2.6.32-754.35.1.el6.x86_64 - OpenJDK 64-Bit Server VM 11.0.20 (Corretto-11.0.20.8.1)
Expected behavior
all update operations result in both records and composite indexes to be correctly updated
Actual behavior
Once again I'm experiencing hard-to-diagnose corruptions of composite indexes. Sometimes composite index become corrupted and they show records that do not match the query criteria
Steps to reproduce
Sorry, I can reproduce it in the production environment, but I'm not able to create a simple test case to be executed. A general description:
What I can give you is a screenshot of the incorrect results of a select query after the index becomes corrupted. As you can see, it is a very weird result, I don't even know how it is technically possible to end up in a situation like this, but maybe it can provide a hint for you to investigate. I also attach the method that I use to perform the update. The method is invoked by an http handler which responds to requests sent by several clients at the same time.
updateOrderAsync.zip