[p5.js 2.0 Bug Report]: p5.RendererGL.js Unit Test fails

[sophyphile]

Most appropriate sub-area of p5.js?

• Accessibility
• Color
• Core/Environment/Rendering
• Data
• DOM
• Events
• Image
• IO
• Math
• Typography
• Utilities
• WebGL
• Build process
• Unit testing
• Internationalization
• Friendly errors
• Other (specify if possible)

p5.js version

2.0.2

Web browser and version

Chrome, 137.0.7151.55

Operating system

MacOS Sequoia 15.1.1

Steps to reproduce this

Steps:

1. Run npx vitest run.
2. The tint should be reset after draw loop test in the tint() in WEBGL mode suite (path: test/unit/webgl/p5.RendererGL.js) is flaky and intermittently times out with the error shown below.

Snippet:

FAIL |unit|  test/unit/webgl/p5.RendererGL.js > p5.RendererGL > tint() in WEBGL mode > tint should be reset after draw loop
Error: Test timed out in 1000ms.
If this is a long-running test, pass a timeout value as the last argument or configure it globally with "testTimeout".

Screenshot:

I have not been able to analyse root cause yet or attempt a fix.

[welcome]

Welcome! 👋 Thanks for opening your first issue here! And to ensure the community is able to respond to your issue, please make sure to fill out the inputs in the issue forms. Thank you!

[davepagurek]

Is this flaky in some way, e.g. if you run just that one test file with npm run test test/unit/webgl/p5.RendererGL.js does it still fail, or is it only when run in combination with all the tests?

[sophyphile]

Hey Dave, yes definitely flaky. It hasn't failed yet on my side when running it independently, and it fails intermittently when running it in combination with other tests.

[davepagurek]

Another thing to test could be parallelism. It looks like by default vitest runs multiple test files in parallel, and on some systems WebGL tests might be too heavy to do that within the 1s timeout? So some things to test could be:

• Does the full test suite pass if you run it without parallelism?
• Does the full test suite pass if you increase the test timeout?

[sophyphile]

Hi Dave, I'll go ahead and test both scenarios. I've regularly seen this particular test fail more often during repeated test runs, as system load progressively increases. That said, I've also occasionally observed failures when launching a first test run on a quiet machine (albeit in parallel with other tests).

I shall test without parallelism first to see if that solves the issue. Otherwise, I suspect increasing the test timeout will help. I'll report back on my findings!