15390404879
88%

Ran 02 Jun 2025 11:04AM UTC

Jobs 1

Files 0

Run time –

Badge

Embed ▾

pending completion

Build # 15390404879

Build Type

push

github

Committed by

locker

Commit Message

box: handle stale multikey tuple fields

After a multikey index is altered or dropped, tuples that were inserted
while it existed still reference the format with multikey parts. Actually,
that multikey format field shouldn't be used anymore because multikey
index is gone, but that's not true. It happens because format is arranged
to a JSON tree, and this tree has an interesting property. Imagine having
a field with path '[1][*]' in the tree. Then, when looking for a field
'[1][1]' (or '[1]["abc"]', the second key can be anything), the field with
path '[1][*]' will be returned since '*' is actually wildcard. Hence,
even if the format is stale and there are no multikey fields in actual
format, we can obtain a multikey field even if we didn't search for it
and `multikey_idx` will be MULTIKEY_NONE in this case. Let's handle this
scenario - simply ignore offset slot when `multikey_idx` is MULTIKEY_NONE
for a multikey field.

This bug could lead to assertion failure in Debug build and UB or even
crash in Release build because when one builds an index over the field
that was covered by multikey index, field map of tuples referencing the
old format would be incorrect - it would store offset of multikey array
instead of actual field.

Closes #11291

NO_DOC=bugfix

Run Details

Jobs

ID	Job ID	Ran	Files	Coverage
1	15390404879.1	02 Jun 2025 11:04AM UTC	519	87.51	GitHub Action Run

Source Files on build 15390404879

Detailed source file information is not available for this build.

tarantool / tarantool / 15390404879
88%

README BADGES
x

Markdown

Textile

RDoc

HTML

Rst

Jobs

Source Files on build 15390404879

tarantool / tarantool / 15390404879 88%

README BADGES x

Markdown

Textile

RDoc

HTML

Rst

Jobs

Source Files on build 15390404879

tarantool / tarantool / 15390404879
88%

README BADGES
x