Misleading ExecutionOutcome record is stored in DB (mainnet)

[khorolets]

As the result of the investigation of the Lake Indexer issue about the missing data we found out that the data in Indexer for Explore Database around specific ExecutionOutcome is incorrect.

select receipt_id, executed_in_block_hash from execution_outcomes where receipt_id = '6QKTEHsLihDgVrdtWYbURA28zF29Xdw5dnfWbDVWHPv4'; receipt_id | executed_in_block_hash ---------------------------------------------+--------------------------------------------- 6QKTEHsLihDgVrdtWYbURA28zF29Xdw5dnfWbDVWHPv4 | 68v7s5fg8inLQ2VVnFvZ375bbbx1akU4kbH8ezo6RyFg (1 row)

The ExecutionOutcome for Receipt 6QKTEHsLihDgVrdtWYbURA28zF29Xdw5dnfWbDVWHPv4 is stored as the one that has been executed in the block 68v7s5fg8inLQ2VVnFvZ375bbbx1akU4kbH8ezo6RyFg (22633808). On the other hand, we couldn't find the ExecutionOutcome in 22633808 block. At first, we thought something wrong with the data stored by Lake Indexer

I have found the missing ExecutionOutcome in block 22635169 (1361 later). While it is expected and totally normal for ExecutionOutcome to appear so much later, it is not fine and not normal for our database record to say it has been included in block 22633808.

I can think of the next action items:

• Check the logic around setting the value of executed_in_block_hash (do we set it the right way?)
• Randomly check other records of ExecutionOutcome to find out whether we have other misleading records.
• Fix logic if needed, and reindex the data to fix the misleading records.

cc @telezhnaya @frol

[telezhnaya]

randomly check other records of ExecutionOutcome to find out whether we have other misleading records

I'll do that. Moreover, I'm doing that not randomly, but entirely, while collecting balance changing events. If I understand everything correctly, that's the only such case that we are aware of for now. If I find anything else, I'll put it here

[khorolets]

I have an assumption that something weird is happening on the Indexer Framework side and it requires some investigation to check it.

I keep this issue assigned to @telezhnaya and me.

@telezhnaya is keeping an eye to find out whether we have more such "misleading" records I am going to check the Indexer Framework when I have the bandwidth for that.

While annoying this issue is not critical for now