Race detected while upgrading cuelang

[rsmith-cs-ux]

Cue version:

$ cue version
cue version v0.13.1

go version go1.24.4
      -buildmode exe
       -compiler gc
       -trimpath true
  DefaultGODEBUG gotestjsonbuildtext=1,multipathtcp=0,randseednop=0,rsa1024min=0,tlsmlkem=0,x509rsacrt=0,x509usepolicies=0
     CGO_ENABLED 1
          GOARCH arm64
            GOOS darwin
         GOARM64 v8.0
cue.lang.version v0.13.0

Issue:

I've been trying to upgrade our version of cue from 0.4.3 to 0.13.1 and have been running into a lot of issues with race conditions using the Go api. Our code is highly parallelized using golang.org/x/sync/errgroup and we're currently calling v.FillPath() before deserializing to a Go struct. Everything "works" (no panics) but one of our tests consistently throws a data race error that is quite troubling and I've tried a number of ways to get rid of it with no success.

Here's the stack trace that I'm seeing:

==================
WARNING: DATA RACE
Write at 0x00c00166c7ba by goroutine 41:
  cuelang.org/go/internal/core/adt.(*nodeContext).insertComprehension()
      /Users/a/go/pkg/mod/cuelang.org/go@v0.13.1/internal/core/adt/comprehension.go:255 +0x1afc
  cuelang.org/go/internal/core/adt.(*nodeContext).scheduleStruct()
      /Users/a/go/pkg/mod/cuelang.org/go@v0.13.1/internal/core/adt/conjunct.go:244 +0xe20
  cuelang.org/go/internal/core/adt.(*nodeContext).scheduleConjunct()
      /Users/a/go/pkg/mod/cuelang.org/go@v0.13.1/internal/core/adt/conjunct.go:101 +0x60c
  cuelang.org/go/internal/core/adt.(*nodeContext).scheduleConjunct()
      /Users/a/go/pkg/mod/cuelang.org/go@v0.13.1/internal/core/adt/conjunct.go:88 +0x1a18
  cuelang.org/go/internal/core/adt.(*nodeContext).scheduleConjuncts()
      /Users/a/go/pkg/mod/cuelang.org/go@v0.13.1/internal/core/adt/unify.go:114 +0x29c
  cuelang.org/go/internal/core/adt.(*Vertex).getState()
      /Users/a/go/pkg/mod/cuelang.org/go@v0.13.1/internal/core/adt/unify.go:64 +0x50
  cuelang.org/go/internal/core/adt.(*Vertex).unify()
      /Users/a/go/pkg/mod/cuelang.org/go@v0.13.1/internal/core/adt/unify.go:156 +0x184
  cuelang.org/go/internal/core/adt.(*nodeContext).completeAllArcs()
      /Users/a/go/pkg/mod/cuelang.org/go@v0.13.1/internal/core/adt/unify.go:584 +0x204
  cuelang.org/go/internal/core/adt.(*Vertex).unify()
      /Users/a/go/pkg/mod/cuelang.org/go@v0.13.1/internal/core/adt/unify.go:311 +0xfa0
  cuelang.org/go/internal/core/adt.(*OpContext).unify()
      /Users/a/go/pkg/mod/cuelang.org/go@v0.13.1/internal/core/adt/eval.go:160 +0x2bc
  cuelang.org/go/internal/core/adt.(*Vertex).Finalize()
      /Users/a/go/pkg/mod/cuelang.org/go@v0.13.1/internal/core/adt/composite.go:1031 +0x84
  cuelang.org/go/internal/core/adt.Unify()
      /Users/a/go/pkg/mod/cuelang.org/go@v0.13.1/internal/core/adt/composite.go:972 +0x284
  cuelang.org/go/cue.Value.Unify()
      /Users/a/go/pkg/mod/cuelang.org/go@v0.13.1/cue/types.go:1725 +0x14c
  cuelang.org/go/cue.Value.FillPath()

If I put a mutex around FillPath then the race is no longer an issue, but doing so kills our performance since we have many different cue definitions that are being evaluated by this service in parallel. Some take several minutes to complete, which in our case doesn't work.

I have been attempting to clone the cue.Context from the existing cue.Value (just to see if that would work). Here's the code I was trying to use to accomplish the clone:

        sourceBytes, err := cueformat.Node(v.Syntax())
	if err != nil {
		fmt.Printf("CUE Format Error: %v\n", err)
		return v
	}

	// Create new context and compile from source
	newCtx := cuecontext.New()
	newValue := newCtx.CompileBytes(sourceBytes)
        if newValue.Err() != nil {
		msg := errors.Details(newValue.Err(), nil)
		fmt.Printf("Compile Error:\n%s\n", msg)
		fmt.Printf("Source:\n%s\n", string(sourceBytes))
		return v
	}

Unfortunately, the syntax that is generated is invalid because the sourceBytes contains comments with // explicit error (_|_ literal) in source.

I'm sure I'm doing something wrong, I just don't know what that might be or if there is another (hopefully better) way of handling this race condition. Thanks in advance for any help you can provide!