osteele / osteele/liquid

Data race in {% cycle %}: renderer closure writes to an error variable captured at parse time

Open Beginner friendly
#150 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Go
Stars
354
Forks
72
PR merge metrics
No merged PRs in 30d

Description

cycleTag builds its renderer closure once, at parse time, and the closure assigns the write's error to the err declared by the compiler rather than to a local one:

https://github.com/osteele/liquid/blob/682200b0d1491cdf96a94fe83036141721070fa0/tags/iteration_tags.go#L44-L68

func cycleTag(args string) (func(io.Writer, render.Context) error, error) {
	stmt, err := expressions.ParseStatement(expressions.CycleStatementSelector, args)  // line 45
	...
	return func(w io.Writer, ctx render.Context) error {
		...
		_, err = io.WriteString(w, values[n%len(values)])   // line 65 — `=`, so this writes the captured err
		return err
	}, nil
}

Because the closure is created once per parse and reused by every render, all renders write to that single variable. Rendering one parsed *liquid.Template from more than one goroutine is therefore a data race.

Practical impact is small: err is only ever non-nil on the FRender-to-a-failing-writer path, so the reachable symptom is one render's write error being returned by a different render's cycle tag. Under go test -race it fails outright.

This looks like the only site — the other tag closures each declare a fresh err with := inside the closure before assigning to it (iteration_tags.go:89, include_tag.go:45, render_tag.go:389,404).

Repro — parse once, render concurrently:

tpl, err := liquid.NewEngine().ParseString(`{% for a in (1..4) %}{% cycle 'a', 'b' %}{% endfor %}`)
require.NoError(t, err)

var wg sync.WaitGroup
for range 16 {
	wg.Add(1)

	go func() {
		defer wg.Done()

		_, _ = tpl.RenderString(liquid.Bindings{})
	}()
}

wg.Wait()

Under go test -race:

WARNING: DATA RACE
Write at 0x00c00011e8f0 by goroutine 9:
  github.com/osteele/liquid/tags.cycleTag.func1()
      tags/iteration_tags.go:65
Previous write at 0x00c00011e8f0 by goroutine 21:
  github.com/osteele/liquid/tags.cycleTag.func1()
      tags/iteration_tags.go:65

The fix is one token (=:=). I'll open a PR with a regression test alongside the existing TestTemplate_Parse_race / TestTemplate_Render_race.

Contributor guide

Open the contributing guide

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.

Research direction

Start with tags/iteration_tags.go:44-68 and the existing TestTemplate_Parse_race and TestTemplate_Render_race tests. Run the concurrent-render reproduction under go test -race; done means the regression test passes without a reported data race.

Written by the indexing model from the issue text.

Assessment

Tech stack
go
Domain
backend, testing-qa
Issue type
Bug
Difficulty
1/5
Estimated time
Under an hour
Activity status
Active
Clarity
Clearly specified
Newbie friendliness
85/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.