Missing keys are dropped from [...] inside select/and/or

[johejo]

Describe the bug

Collecting a missing key into an array normally produces [null],
but inside a select/and/or condition the missing key is dropped.

Version of yq: 4.53.3
Operating system: mac
Installed via: built from source

Command

yq -n '{} | ([.a] | length)' # 1 (ok)
yq -n '{} | select([.a] | length == 1)' # no output (expected {})
yq -n '{} | (true and ([.a] | length == 1))' # false (expected true)

Actual behaviour

$ yq -n '{} | ([.a] | length)'
1
$ yq -n '{} | select([.a] | length == 1)'
$ yq -n '{} | select([.a] | length == 1)' | wc -c
0
$ yq -n '{} | (true and ([.a] | length == 1))'
false

Expected behaviour

[.a] should be [null] (length 1) everywhere, as it is at the top level (and as in jq):

Additional context

The case in which I actually became aware of this issue was a bit more complex,
But I got advice from Claude and Codex when creating the minimal reproduction case.

[vjymisal0]

Had a dig at this. The two cases differ because of DontAutoCreate.

[...] (collectOperator) evaluates its RHS in context.SingleChildContext(candidate), but select, and and or evaluate their condition in context.SingleReadonlyChildContext(candidate), which sets DontAutoCreate. traverseMap only synthesises the missing key when that flag is clear:

if !splat && !prefs.DontAutoCreate && !context.DontAutoCreate && newMatches.Len() == 0 {
    // no matches, create one automagically

So [.a] collects one node at the top level and none inside a condition — hence length 1 vs 0.

Worth noting before picking a fix: the top-level [null] is not a detached null, it is the auto-create path actually writing the key into the document:

$ printf '{}\n' | yq '[.a] , .'
- null
a: null      # <- the input document now has the key

whereas the readonly context deliberately avoids that:

$ printf '{}\n' | yq 'select(true) , .'
{}
{}

That seems to be exactly what SingleReadonlyChildContext is for — keeping select(.a.b) from mutating documents as a side effect of testing a condition.

So making [.a] behave like jq inside conditions is not just a matter of dropping the readonly context there — that would let conditions mutate documents again. It looks like it needs missing-key traversal in a readonly context to yield a detached null rather than either mutating or yielding nothing, which changes evaluation semantics for every select/and/or. Happy to put a PR together if you can say which way you'd like it to go.