Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

query: Read null like jq in key steps, comparisons and contains()

Open
  • Is something wrong?
#152 3 comments 0 reactions 1 assignee View on GitHub

Maintainers usually reply within 1 day

@mojatter is already working on this.

Since Oct 25, 2026.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
55/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
go
Domain
backend, cli

Research direction

Start with MapQuery.Exec, ArrayQuery.Exec, ContainsQuery.Exec, and wordValue in parser.go, then trace how NilValue is handled by comparisons and selectors. Reproduce the listed cases and check count() and type() behavior when choosing whether null steps return no result or Nil. Done means the null cases match the expected jq results and the changed behavior is covered by tests.

Written by the indexing model from the issue text.

Description

bug

Reading null disagrees with jq in three places:

Input Query tree jq
{"a":null} .a.b cannot index array with "b" null
{"a":[null]} .a[0].b cannot index array with "b" null
{"a":[null,{"x":1}]} .a[.x == 1] cannot index array with "x" {"x":1}
[{"age":1},null] .sort(.age) cannot index array with "age" [null,{"age":1}]
{"a":[[null],[1]]} .a[.[0] != null] [[null],[1]] [1]
{"a":[[null],[1]]} .a[.[0] == null] nothing [null]
[null,1] .contains("") true — (no empty string in the array)
  1. Key and index steps: MapQuery.Exec and ArrayQuery.Exec return an error for every value type, NilValue included.
  2. Comparisons: the parser has no null literal (wordValue in parser.go only knows true, false and numbers), so null becomes the string "null", and NilValue.Compare treats != against it as true and == as false.
  3. contains(): elements are compared by Value().String(), and NilValue.String() is "", so a null element matches contains("").

Since #150, a Go nil element reads as null too, so arrays with holes left by growth hit all of these as well, e.g. any selector over .a after .a[2] = 1.

Fix:

  • Return no result (or Nil) from MapQuery.Exec / ArrayQuery.Exec on null, and decide which, since a selector treats "no result" and null the same but count() and type() do not.
  • Parse null as Nil in wordValue, and decide what = null means in an edit RHS (it is parsed as YAML there and already gives Nil).
  • Skip null elements in ContainsQuery.Exec, or compare by type.

This changes observable behaviour: queries that errored on null start succeeding, and comparisons with null flip.

Dominant language
Go
Stars
7
Forks
2
Avg merge
11h 12m
Merged PRs (30d)
43

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from mojatter/tree

All issues in mojatter/tree

Similar issues

More Go issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.