Corrupt composite indexes after bulk insert

[vic0824]

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:

• create table Order with a unique index on field id and a unite composite index on (status, id)
• insert records with status = 'PENDING'
• update records with status 'COMPLETED'
• select records with status = ' PENDING'
• verify that the query returns both records with status = 'PENDING' and records with status = 'COMPLETED'

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

[gramian]

Could you try adding @rid to the projection and see if the error persists?

[vic0824]

I know the problem is the index, because if I drop the index and repeat the query, I get the correct results.

[vic0824]

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.

[vic0824]

It has happened again: I attach:

• a screenshot of the query (including the rid) and the first records of the results
• the csv export of the full results of the query

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.

query_result.csv

[vic0824]

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

[vic0824]

I have updated the issue title, as it appears to be linked to the bulk insert, rather than the update

[vic0824]

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?

[lvca]

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.