[arcaven]

yqlib cannot currently be used from more than one goroutine, and the fix is small: the evaluators call InitExpressionParser on every Evaluate, so concurrent callers build a parser at the same time. This wraps that initialization in a sync.Once. The CLI is unaffected either way, since cmd/root.go already initializes once at startup.

Details and a standalone reproducer are in #2788.

What races

Two package level things get written on each call:

• ExpressionParser itself, guarded only by a nil check.
• The ParticipleTokenType field on each shared participleYqRules entry, which newParticipleLexer fills in while building the lexer. Another goroutine can be reading those through getYqDefinition.

Both are pointer and struct field writes rather than map writes, so the runtime does not stop the process. It corrupts quietly, which is probably why this has gone unnoticed.

The change

InitExpressionParser now does its work inside a sync.Once. The nil check stays inside it, so a caller that assigns ExpressionParser itself is still respected. Nothing else in the tree assigns that variable, and no test resets it, so behaviour is otherwise unchanged.

Test

TestInitExpressionParserConcurrent in pkg/yqlib/lib_test.go.

One honest caveat about it. Reproducing the original race needs a process where nothing has initialized the parser yet, and in a full package run expression_parser_test.go sorts before lib_test.go and initializes it first. So the reproducing command is the test on its own, which is in a comment above it:

go test -race -run TestInitExpressionParserConcurrent ./pkg/yqlib/

On master that reports data races in newParticipleLexer and getYqDefinition. With this change it passes. In a full run the test still exercises concurrent initialization, it just cannot be the one that triggers the first init.

I noticed scripts/test.sh does not pass -race, so this test will not catch a regression in CI as things stand. Happy to add a -race run if you would like one, but that felt like your call rather than something to slip into a bug fix.

go build ./..., go vet ./pkg/yqlib/ and gofmt are clean. go test ./pkg/yqlib/ has one failure, TestTomlScenarios, which fails identically on master here, so I have left it alone.

[Copilot]

Pull request overview

This PR makes pkg/yqlib’s expression parser initialisation safe under concurrent use by guarding InitExpressionParser() with a package-level sync.Once, addressing the data race described in #2788 and aligning library behaviour with the CLI’s one-time startup initialisation.

Changes:

• Wrap InitExpressionParser() initialisation logic in sync.Once to prevent concurrent parser/lexer construction.
• Add a concurrency-focused test intended to reproduce/guard against the original race under -race.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.

File	Description
pkg/yqlib/lib.go	Adds sync.Once guarding to make InitExpressionParser() concurrency-safe.
pkg/yqlib/lib_test.go	Adds a new concurrent initialisation test for InitExpressionParser().

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[arcaven]

This builds as written: range over an integer has been legal since Go 1.22, and go.mod declares go 1.25.0.

Go's own error names the condition, from the same snippet compiled at go 1.21:

cannot range over goroutines (untyped int constant 32): requires go1.22 or later

So the note would hold under a pre-1.22 language version. At 1.25.0 the package vets clean and the test runs.

[arcaven]

Fixed in 77912bd. The precedent is right: pkg/yqlib uses UK spelling in prose (operator_reduce.go:13, decoder_ini.go:20).

[arcaven]

Fixed in 77912bd, along with the same word in the t.Fatal below.

[arcaven]

77912bd applies the spelling fixes.

Verification for the concurrency test, at pinned SHAs on clean trees (macOS arm64, go1.25.4):

	exit	verdict
master e2f1d5c + this test only	1	fails 5/5
this branch 77912bd	0	passes 5/5, no races

go test -race -count=1 -run TestInitExpressionParserConcurrent ./pkg/yqlib/

The detector's warning count varies per run (4 to 10); the verdict was stable across all ten. So the test guards the behaviour rather than passing either way.

Separately, TestTomlScenarios fails for me at e2f1d5c without this branch's changes, so it looks pre-existing. It may be my environment; happy to file separately if it reproduces for you.

[mikefarah]

Fixed in 4.53.4