Skip to content

Investigate intermittent JsVar concurrent broadcast test failure #408

Description

@linkdata

TestJsVarConcurrentBroadcastsKeepLatestMutation can observe the earlier Set and fail under -race. During the first full JAWS_REQUIRE_NODE=1 go test -race ./... run on PR #407 (708d9b4), it failed at lib/ui/jsvar_order_test.go:171:

broadcast = "value=\"first\"", want latest mutation

The focused test then passed 10/10 and 100/100 runs under -race; a subsequent full race suite also passed. PR #407 does not change lib/ui or Set batching.

The test blocks the first write during JSON marshaling, starts a second write, then waits 100 ms before releasing the first. JsVar serializes writes, so the second cannot finish before that release. Outgoing Sets flush on a 100 ms tick. Depending on tick phase and scheduling, the first and second writes may fall into separate batches. The test reads only the first Set and requires it to contain second, even though the documented coalescing guarantee applies to writes in one batch and an intermediate first Set may be valid.

Determine whether the failure is a test assumption or an ordering defect. If intermediate Sets across ticks are valid, update the test to check that the final delivered value is second (while allowing an earlier first frame), or arrange for both writes to be pending before asserting coalescing. If the browser can finish with first after the second write, fix the implementation and add a regression test.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions