Skip to content

Flaky test: TestSubscribeWithContextDone #186

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
n-peugnet opened this issue Feb 20, 2025 · 0 comments · May be fixed by #187
Open

Flaky test: TestSubscribeWithContextDone #186

n-peugnet opened this issue Feb 20, 2025 · 0 comments · May be fixed by #187

Comments

@n-peugnet
Copy link

While packaging this library in Debian, we noticed that the test TestSubscribeWithContextDone is flaky. It can fail, for example when the machine has a high load while running the tests:

[...]
=== RUN   TestSubscribeWithContextDone
    client_test.go:423: 
        	Error Trace:	client_test.go:423
        	Error:      	Not equal: 
        	            	expected: 32
        	            	actual  : 30
        	Test:       	TestSubscribeWithContextDone
--- FAIL: TestSubscribeWithContextDone (2.00s)
[...]

One way to reproduce this failure reliably is to pin the execution on a few CPUs, for example with taskset (thanks Santiago Vila for the reproducer):

$ taskset -c 0,1 go test
--- FAIL: TestSubscribeWithContextDone (2.00s)
    client_test.go:423: 
        	Error Trace:	client_test.go:423
        	Error:      	Not equal: 
        	            	expected: 30
        	            	actual  : 28
        	Test:       	TestSubscribeWithContextDone
FAIL
exit status 1
FAIL	github.com/r3labs/sse/v2	12.500s

See also: https://bugs.debian.org/1098392

n-peugnet added a commit to n-peugnet/sse that referenced this issue Feb 20, 2025
Instead of comparing the number of goroutines which is inherently
unreliable, we count the number of goroutines that exited using a defer
statement, and an atomic counter.

By the way, the timer are reduced to 10ms as it is more than enough time
to let the goroutines exit.

Closes: r3labs#186
@n-peugnet n-peugnet linked a pull request Feb 20, 2025 that will close this issue
n-peugnet added a commit to n-peugnet/sse that referenced this issue Feb 20, 2025
Instead of comparing the number of goroutines which is inherently
unreliable, we count the number of goroutines that exited using a defer
statement, and an atomic counter.

By the way, the timer are reduced to 100ms as it is more than enough time
to let the goroutines exit.

Closes: r3labs#186
n-peugnet added a commit to n-peugnet/sse that referenced this issue Feb 22, 2025
Instead of comparing the number of goroutines which is inherently
unreliable, we count the number of goroutines that exited using a defer
statement, and an atomic counter.

By the way, the timer are reduced to 10ms as it is more than enough time
to let the goroutines exit.

Closes: r3labs#186
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant