[Bug] AQL inbound graph query v is path.vertices[0] instead of path.vertices[1]

[baslr]

My Environment

• ArangoDB Version: 3.10 heads/devel-0-g9715ebd541e 9715ebd
• Deployment Mode: Single Server
• Deployment Strategy: Manual Start
• Configuration: default
• Infrastructure: aws linux vm
• Operating System: 5.15.0-1013-azure Ubuntu 22.04
• Total RAM in your machine: 16 GB
• Disks in use: SSD

Component, Query & Data

Affected feature: AQL graph query

AQL query (if applicable):

// run this query and alternate commenting out one of the let str
// with let str = 'abc' the query will assert
LET doc = (FOR d IN test_2
    FILTER d.token == 'asdf'
    RETURN d)[0]
FILTER ASSERT(doc != NULL, 'doc not found')

LET doc1 = (FOR v,e IN INBOUND doc test_12test_2
//    let str = v._id + ' ' + e._from + ' ' + e._to
        let str = 'abc'
    FILTER ASSERT(v.val == 'helloo', concat('helloo not found ', str))
RETURN v)[0]

return doc1

Dataset:

// setup
INSERT {
    val: 'helloo'
    } INTO test_1
LET newT1 = NEW

INSERT {
    token:'asdf' } INTO test_2
LET newT2 = NEW

INSERT {
_from: newT1._id,
_to: newT2._id } INTO test_12test_2

Steps to reproduce

1. create collections and run insert query
2. execute query and comment out one of the let str

Problem:
Without accessing v, v is not the test_1 document but the test_2 document. You can verify that by
asserting out v._id.

Expected result:
v is the inbound collection.

Build via cmake ...

/build/bin/arangod --version
3.10.0-devel

architecture: 64bit
arm: false
asan: false
asm-crc32: true
assertions: false
avx: true
avx2: true
boost-version: 1.78.0
build-date: 2022-07-21 15:20:51
build-repository: heads/devel-0-g9715ebd541e
compiler: gcc [11.2.0]
cplusplus: 202002
curl-version: none
debug: false
endianness: little
failure-tests: false
fd-client-event-handler: poll
fd-setsize: 1024
full-version-string: ArangoDB 3.10.0-devel [linux] 64bit, using jemalloc, build heads/devel-0-g9715ebd541e, VPack 0.1.36, RocksDB 7.2.0, ICU 64.2, V8 7.9.317, OpenSSL 3.0.2 15 Mar 2022
icu-version: 64.2
ipo: false
iresearch-version: 1.2.0.0
jemalloc: true
libunwind: true
license: community
maintainer-mode: false
memory-profiler: false
ndebug: true
openssl-version-compile-time: OpenSSL 3.0.2 15 Mar 2022
openssl-version-run-time: OpenSSL 3.0.2 15 Mar 2022
optimization-flags: -march=skylake-avx512 -msse2 -msse3 -mssse3 -msse4.1 -msse4.2 -mavx -mfma -mbmi2 -mavx2 -mavx512f -mavx512vl -mavx512cd -mavx512dq -mavx512bw -mno-sse4a -mno-xop -mno-fma4 -mno-avx512pf -mno-avx512er -mno-avx512ifma -mno-avx512vbmi
pic: 2
pie: 2
platform: linux
reactor-type: epoll
replication2-enabled: true
rocksdb-version: 7.2.0
server-version: 3.10.0-devel
sizeof int: 4
sizeof long: 8
sizeof void*: 8
sse42: true
tsan: false
unaligned-access: true
v8-version: 7.9.317
vpack-version: 0.1.36
zlib-version: 1.2.12

The problem also exists at e2065fe

// with accessing v the query works

// without accessing v, v is path.vertices[0]

[baslr]

bf44062 still throws the error.

[baslr]

537e7de still throws the error.

[baslr]

a8ded6a still throws the error.

[mchacki]

This PR is going to fix the issue.
#16622

[mchacki]

Thank you for reporting this 👍